Why Deleting Old Code is the Dumbest😒 Move There Is

                                                                           Photo by Orimi Protograph on Unsplash

The idea that new code is inherently better than old code is a prevalent ideology that isn’t based on fact.

I wouldn’t much care about it, but this ridiculous idea keeps coming back in new guises and causing damage to generations of programmers. Old code has been battle-tested, so what is this movement to throw out proven solutions with the trash as if the new is naturally superior to the old?

What is going on here?

A Trip Down Memory Lane

In the olden days people used to use “a clean slate” as marketing copy for their software.

Quattro Pro was released to compete with Microsoft Excel but needed a push to make a real dent in Microsoft’s market share. The secret sauce was that Quattro Pro was written from scratch, and Philippe Khan (Borland founder) was all over the press boasting about the codebase being created from scratch.

This idea was idiotic then. It’s idiotic now. Old code has been used, abused and tested in the field. Bugs have been squeezed out of the code, and the resultant functionality comes out stronger.

I haven’t seen a press release referring to the codebase as being “new” for a long time, but I see that software developers keep pushing the same idea that the new is better than the old — and this attitude needs a reality check.

Code Doesn’t “Go Bad”

Let me give it to you straight. The code doesn’t magically get bad because it’s old. It doesn’t decay, there aren’t digital moths that eat the bits that make up your code. That’s because your code isn’t a 1968 Dodge Charger sitting in a garage.

People still don’t seem to get it. I had a former boss who shared their “opinion” on our code base soon after joining the company. 

“We should delete the project and start fresh”

I mean ok, fair enough. What is the reasoning behind this insight? Someone on Twitter agreed with them that it would be a good idea. I can’t agree with that reasoning, and how would we test the codebase?

The False Allure Of New Code

New Code brings the delusion that the new is better. Remember when furniture used to last for decades, and then Ikea produced wardrobes that last a few years and people thought they were “better” because they were flat-packed? That, but with code.

The reality is that reading code is more difficult than writing code. Today’s new code becomes tomorrow’s old code which is difficult to understand and maintain. Older code has already gone through code review, testing and even production meaning that the code is, by definition, good.

Next Time

Bugs can take weeks of real-world usage before they are found. Once they are found a programmer needs to reproduce the bug and fix it. It then needs to go back through the QA process and back into production.

Next time you think the new is better than the old, consider this. Don’t throw away work unnecessarily.

If you want to rewrite do it with consideration. Think about optimization. Think about where optimizations can be made by iteratively improving the code.

Because when you start again you believe that you are going to do a better job than the code that is currently there. Why do you believe that? What evidence do you have?

Maybe, just maybe use data on this one? Yes?

Conclusion

You might want to refactor a class to make it easier to use. That might pay dividends and improve the codebase. Well done you! I’m not in a company that allows that, so if you have that opportunity, I envy you.

Throwing away the whole codebase? You really need to consider this approach. I mean, are you really sure? If you’re considering throwing away battle-tested code for new code, you should make sure, your code is better than the one it replaces — if not what is the point?