Anatomy of Ugly: How Good Code Goes Bad

Computerworld - Like babies, most code is born beautiful, at least in the eye of its creator. But the only time I ever heard one programmer praise another's code was prerelease. In this newborn state, the code reflects the developer's original design, untouched by the unknown demands of future users.

But once code enters into use, this innocence is lost. Just as the wrinkles on a person's face are carved by his experiences, so do missed requirements, bug fixes and -- especially -- code being adopted by another programmer all result in additions and patches that become downright ugly. And no programmer wants to work with ugly code.

This leads to the inevitable desire to rewrite the code from scratch. The reasoning is seductive, and I have fallen for it many times: It would be easier to rewrite it than to try and fix it, because it's so messy that it's hard to understand. I've even justified it to myself on the grounds that it will increase the developer's accountability, since it's easy to blame problems on the legacy code.

There is some truth in this. If a developer doesn't understand the purpose of code written by others, he is more likely to leave it and write around it than to remove it, so the code becomes bulky and confusing. Rewriting it can serve to streamline the code, making it easier to follow and understand.

But there is also a hidden trap, as I have confirmed over and over: The problem is that the developer who wants to rewrite it doesn't understand it, which is why it needs to be rewritten.

Think about that. How can you recreate something you don't understand?

You can't, of course. So, what happens is that all of the battle scars of the code -- that is, the code added to handle unforeseen issues such as undocumented idiosyncrasies in the operating environment -- are lost, and with them the hard-won experience that required the code to begin with. The new code must literally grow up all over again, until it, too, becomes ugly.

Let me give you an example. We have a product that interacts with a browser, the Document Object Model (DOM) and the operating system. Once our first version went into production, we began to uncover an endless procession of subtleties, undocumented behaviors and outright bugs in each of these interactions. In one case, we discovered that passing a URL that was in a different domain than the one that initiated it had to be