By 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.
Share:
"Beautifully" done!
I've got to ask - what does the "beautiful" code do?
The beautiful code example is some Haskell code from the Beautiful code blog: http://beautifulcode.oreillynet.com/2008/03/four_lines_of_code_1.php
Interestingly the comments on that page discuss how difficult it is to understand as well, so I thought it was a great example of something that is beautiful once you get your head around it but on first glance is likely to make your head explode. That effect being the exact feeling cartoon code attempts should avoid.
Obviously, beauty is in the eye of the beholder. The haskell code is NOT beautiful code; as stated above, even experienced haskell programmers have problems getting their head around it.
Just as you don't need to understand mechanical engineering to see that the e.g. Golden Gate bridge is beautifull, you shouldn't need to be an experienced coder in a given language to appreciate a beautiful piece of code in that language
Yes, let's compare a complex piece of Haskell code with a hello world class in Ruby.
Next time, write the Haskell function the way Haskellers would, and write the same function in Ruby the way Rubyists would. Let's see then which is more readable.
The point is not whether Haskell code or Ruby code is easier to read. It's that easy-to-read code is A Good Thing.
Awesome!