Summary
Part I - Beauty and The Beast. I begin my exploration of ugliness in code with some background and an overview of what most people consider to be crappy code.

90% of everything is crap. - Sturgeon’s Law (one of many variants)

When applied to software, Sturgeon’s Law is hopelessly optimistic. - Savoia’s Corollary to Sturgeon’s Law

O’Reilly just released a book called: Beautiful Code – Leading Programmers Explain How They Think. And, while I am probably not worthy of having my words and code share the same book spine as the work of CS legends such as Brian Kernighan or Jon Bentley, I am quite proud to have contributed a chapter entitled “Beautiful Tests.”

You should definitely get a copy of Beautiful Code; it’s 500+ pages of great insights into the thinking process of some great programmers (plus me). And, on top of that, all the royalties from the book will go to Amnesty International.

But this blog is not about beautiful code; it’s about its evil twin: nasty, ugly, convoluted, and hard-to-understand code. It’s usually the kind of code that other people have written – and you inherit because they left the company. It’s the kind of code that elicits a common reaction when it shows up on your IDE’s doorstep: “Crap!” – pardon my French. Or: “Merde!” – pardon my English. It’s the kind of code that, in some parts of the world, gets you fired – not the lame HR firings we have in the US, but the ones that involve a firing squad and bullets, and rescue calls to Amnesty International.

Hell is other people. - J. P. Sartre

Hell is other people’s code. - T-Shirt seen recently in Mountain View, CA

While I was writing my chapter of Beautiful Code, and reviewing some of the other chapters, I was forced to think beyond code functionality and efficiency. I had to think about beauty in code. And thinking about what makes a particular piece of code beautiful also made me think about the complementary question: What makes a particular piece of code crappy?

In the last few months, this question has led to heated conversations with colleagues, friends in the business, and random software engineers sitting next to me at the local coffee house. It would be naïve to expect programmers to unanimously agree on anything, but on the subject of crappy code most people I talked with agreed on a few of things:

First. There’s a lot of ugly code out there. Most of the underlying code in the software that runs our world is at the opposite end of beautiful. It's important to note that bad code does not necessarily imply crappy, useless, software applications. There’s a big difference between software and code. Software is the finished working product; it’s what the end user sees and experiences. Code is the guts of software; it’s what the programmer sees and experiences. It’s not only possible to have very useful software that’s built on crappy code – it’s the norm.

Second. Most programmers have a pretty high tolerance for working with ugly code – as long as they were the ones who wrote it. That’s either because they think their code is beautiful – in the same way every parent thinks their children are beautiful, or because it’s ugly in a way that they are familiar with. But their tolerance level drops dramatically when they have to deal with someone else’s code: Crap is other programmers’ code.

Third. Most software organizations don’t seem to care much about how bad the underlying code is – as long as the software does what it’s supposed to and the people who wrote it stick around to maintain it. If they did care they would have better measures to prevent ugly code from contaminating key components of their precious applications. A quick glance at the code in most software will show you that that’s not the case. There’s crappy code everywhere.

At some point or other, however, some key developers decide to leave the company – often because they can no longer stand to work with the mess of code they have created. That’s when bad code rears its ugly head and has to be dealt with. That’s when the search for victims to inherit the crappy code base begins.

Which leads us to the big question:

Most people agree that there is a lot of ugly code out there, but most developers are not able to see their own code as bad. Can we come up with an objective and easy-to-calculate measure of code crappiness, based on unassailable research and experimentation, that everyone could agree on?

The answer – unless you are hopelessly optimistic and painfully naïve – is a definite no.

But we can come up with a somewhat-objective measure of code crappiness based on previous research, some hard-earned experience, and, yes, some personal beliefs and preferences.

But this blog entry is already a bit too long so you’ll have to wait a couple of days for that. In the meantime, you might want to think how you would go about measuring code crappiness?

Summary of Part I (for people with really bad short-term memory)

Writing for the book Beautiful Code, made me think about the opposite of beautiful code – ugly code. By talking to a bunch of software people I have come to the conclusion that most developers associate crappy code with other people’s code – especially other people’s code that they have inherited and will have to maintain and work with. I have also come to the conclusion that – as long as the software works – most software organizations don’t really care about how bad their own code is … until the programmers who created it are no longer around. And by then it’s too late.

Preview of Part II (for people who are wondering if it’s worth coming back for more abuse)

By now, I have probably offended, insulted, or antagonized most of the readers – and this is only Part I. In Part II things are going to get even more fun because I will introduce a new software metric: the C.R.A.P. index. Yes, you heard me right. This is just what the software industry needs: another metric.

C.R.A.P. stands for Change Risk Analysis and Predictions. As the (mildly offensive, but hopefully memorable) name implies, the C.R.A.P. index is designed to analyze and predict the risk and effort associated in changing (maintaining and enhancing) an existing body of code – particularly (but not necessarily) by developers other than the original developers. It should be fun, hope to see you back for Part II.

Talk Back!

Have an opinion? Readers have already posted 61 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Alberto Savoia adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Alberto Savoia is founder and CTO at Agitar Software, and he has been life-long agitator and innovator in the area of software development and testing tools and technology. Alberto's software products have won a number of awards including: the JavaOne's Duke Award, Software Development Magazine's Productivity Award, Java Developer Journal's World Class Award, and Java World Editor's Choice Award. His current mission is to make developer unit testing a broadly adopted and standar industry practice rather than a rare exception. Before Agitar, Alberto worked at Google as the engineering executive in charge of the highly successful and profitable ads group. In October 1998, he cofounded and became CTO of Velogic/Keynote (NASD:KEYN), the pioneer and leading innovator in Internet performance and scalability testing. Prior to Velogic, Alberto had 13-year career at Sun Microsystems where his most recent positions were Founder and General Manager of the SunTest business unit, and Director of Software Technology Research at Sun Microsystems Laboratories.