An old article from Joel Spolsky, but one that offers some timeless advice to all developers and product managers.

Actually, my title is wrong - it should say “Don’t Rewrite WORKING code, Refactor”.

Like Joel says, developers have an automatic urge to destroy an unfamiliar codebase and re-build software in their own image. Part of this is simple ego, but mostly it comes down to an important point - “Code is easier to write than to read”.

When you see a constructor for a piece of business logic consisting of 368 lines littered with seemingly random, mis-placed calls to the database, and, god-forbid, UI generation, the first instinct is that the codebase is un-maintainable and you’d be better off starting over.

This is almost always a horrible mistake. If you’re dealing with a long-lived codebase that WORKS, it works BECAUSE of those horrible assaults on programming paradigms. Joel reminds us that that constructor is the way it is likely because of bug fixes - months or even years of real-world use exposed edge-cases not considered by the original developers. By scrapping working code and starting over, you’re not just throwing out working code, you’re throwing out the invaluable knowledge of these edge cases.

This is something I’ve personally struggled with over the years. I have ancient code kicking around on hard drives and live sites from the past that has plenty of “WTF was I thinking!?!?”s in it. I have seriously considered tossing the whole thing in the garbage and starting over but have resigned myself to the idea that the more efficient use of my time is to refactor that codebase little by little to better support new features.

By the time I catch up and “break even” in terms of a functioning product by starting over, I’d have likely already implemented dozens of new features and made significant improvements to the old codebase instead.

Old code isn’t necessarily bad code, just misunderstood.