Revisiting old code

Code does not grow old. If you take a copy of Microsoft DOS, the compiled code will still perform what it was intended to do. It was fine before, and it is fine today. Our needs may have changed but the code itself is intact and robust as it always was.

When Netscape realized that Internet Explorer was a fierce competitor (some say unfair competitor), they decided to build a better web browser. One that will blow away the competition. The first thing they did was to revisit their old code. And that old code stunk according to them. So they tossed it away like rotten meat and started with a blank sheet.

What they didn't realize was that old stinking code they threw away was the very thing that kept them in business. It was the same code that ran on millions of computers and allowed people to access the web. Sometimes it was slow, sometimes it crashed, but most of the time it was the best browsing experience available.

By tossing it away, they also discarded years of work. Bugs that were painfully discovered and fixes that made the browser work in edge cases were all to disappear in favor of a brand new clean sheet. Imagine a business throwing away its core and already successful product in hope of creating something new from the ground up.

That's just what Netscape did, and that's why they disappeared from the game.

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it. — “The Thing” by Chesterton

When revisiting old code, it is inevitable to feel like it is the worst code you've ever seen. I built many applications that I am affraid to revisit today because I know I will try to discard it. But that's OK. Instead of trying to discard it, there is the option to improve upon it.

I worked on a web project before where we used Symfony as a framework. The way it was coded defeated the purpose of using a framework. There were database queries in the view, the controller, the model, and even some config files. Updating anything was a nightmare. But after the holidays traffic settled, we had plenty of time to revisit our code.

We didn't start a new branch and recreated the website from scratch. Instead, we moved one query at a time to the model. At the same time, we worked on the feature requests from the business entity. The upgrade of the code was not even noticed. Before long all our code was well organized and sucked much less.

It is easy to mistaken working code versus something appealing to the user. If the past few years has taught us anything is that UI is a very important part of an application. The problem is, a lot of people saw it as the only important part of the application. That's why you see applications with beautiful user interfaces that simply fail to deliver their functionality.

Old code, or old work is not something that rots and needs to be discarded before it contaminates its neighbors. When revisiting old code, think about how you can improve it instead of getting rid of it.

---