Note for the easily offended: I know that these blogs are supposed to be about beautiful code, but I believe that by exploring its opposite – nasty, ugly, horrific code – we will enrich our discussions of, and appreciation for, code beauty. I am also aware that the opposite of beautiful is ugly, not crap; and I realize that the term crap is mildly vulgar. I decided to use the word anyway because that’s the term most programmers use when referring to offensively ugly code. In other words, I heard the expression “This code is crap!” much more often than “This code is ugly!” Besides, Wikipedia says that “… [crap] is considered mild enough that even a child may use it informally.” So there :-).

Hell is other people. - J. P. Sartre

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

While writing my chapter for Beautiful Code, 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. Crap is usually another programmer’s code. Most programmers have a pretty high tolerance for working with less-than-beautiful 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. Unfortunately, most developers spend most of their time working with, and maintaining, other people’s code - which explains the next area of agreement.

Second. There’s a lot of crappy 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 bad or 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. These are two very different experiences; like the experience of a diner enjoying a sausage, and that of the meat plant worker making that sausage. It’s not only possible to have very useful and successful software that’s built on crappy code – it’s the norm. Which leads to the next area of agreement.

Third. Crappy code is expected and tolerated. 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 do and it makes money. If they did care they would have better measures to prevent nasty 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. But at some point, if the product is successful, they will have to care (see next point).

Fourth. Crappy code becomes a real big issue when it changes hand and has to be modified. At some point or other 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 the search for victims to inherit and maintain the code base begins, and that’s when crappy code rears its ugly head and has to be dealt with.

The bottom line is that most people agree that the real big problem with crappy code manifests itself when the code has to be changed. And the problem gets much worse if the original developers are no longer around – or haven’t worked on the code for a while so they can’t remember what they were thinking at the time.

Since, eventually, most successful software will change hands and will have to be updated and maintained, the problem of crappy code is a serious one. This raises some interesting questions:

Is crappy code easier to identify than beautiful code? Beauty might be in the eye of the beholder, but is ugliness is universally recognized?

Are there some common characteristics of code that would make most developers who have to inherit it and maintain it say: “Oh crap!” when they see it?

Are those characteristics quantifiable and measurable?

If so, we could build a crap code detector. Wouldn’t that be fun – and possibly even useful?

As you might guess, I’ve been thinking about the problem of crappy code for quite a bit recently. I’ll be sharing my thoughts in the next few blogs; I’ll even go out on a limb and propose a way to detect crappy code.

But in the meantime, what do *you* think? What code characteristics would make you say: “Pardon my French, but this code is crap!” What code would make you recoil in horror at the thought of having to maintain it?

Alberto

P.S. An earlier version of this blog entry appeared on Artima a couple of months ago, before the Beautiful Code blog was started. You might want to check some of the comments it elicited at the time: Pardon My French ... comments on Artima