推荐订阅源

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 invoked in a completely different way due to security patches. This was only one small example of perhaps hundreds of minute but serious issues.

The process, frankly, took years and is still going on, since each of these components, including ours, is a moving target. The problem is that you don't know what you don't know until you find out the hard way, and the code reflects it.

Over the years, the code has become desperately ugly, and to no one's surprise, the developers want to rewrite it. It's so Byzantine, they say, that every time they touch it something else breaks. And, based on the turnaround time to get a fix, it clearly takes too long to diagnose the issue in the first place.

Se here's my dilemma. Should I resist rewriting this time because I realize the value that is represented in those wrinkles and scars? If we rewrite it, I have no doubt we will rediscover all of those same traps, with maybe a few solved but new ones added. And even though the code will be beautiful at first, I also know that won't last. It will also become ugly, and at least I generally know what the old code does and doesn't do.

Or should I give in to the rewrite? Maybe code has to be rewritten every few years to keep it fresh and up to date. Maybe code gets so bloated and ugly that it eventually collapses of its own weight.

What do you think? If you care, share your insights with me. I could use them.