Aiming for 'cartoon code' first

By Russell Miles

In these days of high tempo projects and agile practices we're seeing a resurgence of interest in the craft of writing great and beautiful code. There are right now whole online areas dedicated to the pursuit and recognition of these examples of great code, and I for one honestly think that's a really great thing.

However, it hasn't always been the case. It wasn't that long ago that the emphasis was on complex modeling tools and heavy, front-end biased processes that shuffled code development to the tail end of a project. This was supposed to result in much more successful software projects and, let's be honest, it didn't. (Click on the image below for a larger version.)

So I see this resurgence of code as being a first class citizen in software development as being a good thing. After all, in the end it's the code that does the job and no matter how many documents you've produced, it's the code and the design decisions it embodies that helps to make your software is a success.

However this post is not about beautiful code. You see, beauty is only half the story. I prefer my code, even the uglier examples, to be first and foremost readable. That's what this post is all about, and I call it "cartoon code."

Cartoon code

You can think of truly beautiful code as being almost the highest form of art. These noble pieces of great algorithmic or structured code really are the pinnacle, and there's lessons for us all. But beautiful code is tricky to achieve, and can even be an expensive endeavour, bordering on over engineering, if pursued too hard. Personally I like my code, at a minimum, to be correct, simple and easy to read. So if beautiful code is high art, I prefer my code to be as universally digestible as regular newspaper cartoons.

Let's use an example. The best code I come across is not actually a Picasso but more of a Calvin and Hobbes. Cartoon code is easily read, doesn't require a masters degree in algorithmic processing to understand, and makes sense today and in a year's time. That's not to say it can't be beautiful too, but the essential thing here is that it is communicable and simple.

 

So what's my point here? Well, if beautiful code is the high art of software development then my argument is that there's still a huge amount of worth in not-beautiful-but-easily-readable code, and I use the term cartoon code for just those qualities.

My take is that it's a developer's responsibility, first and foremost, to produce cartoon code. Most of the coding I do as a consultant, and in fact most of the coding done all over the world regardless of domain, is written once but read many more times, often by people that have never met the original coder.

Easy to understand, easy to maintain, straightforward, does-what-it-says-on-the-can code is therefore a necessity. Sometimes that leads to something truly beautiful, and that's really great too. However, call me a pragmatist but the main thing for me is that my code works and others can understand it. Beauty is almost a bi-product, albeit a great one that is often based on blurry factors such as taste and language affinity. Working, simple, maintainable and flexible; those are the qualities I'm looking for my software.

 

Bottom line, if all the code I came across was cartoon code then I'd be a much happier developer. I can appreciate a coding masterpiece, even if that appreciation takes a bit of learning to understand its beauty, but give me easy to read and working cartoon code any day.

 

 

Comments

---

 

Post a comment:

Name

Website

Save?

Email Address (required)

Comments