This month I want to highlight an article, Things You Should Never Do, Part I, by Joel Spolsky. The author describes why rewriting code is often a bad idea, with real-world examples of the practice causing businesses to fail. This article is over 20 years old, and yet the advice remains as valid today as it was back then.

Joel’s experience mirrors – and informs – my own. Rewriting code is a tempting option when an engineer is faced with enhancing a product because every wart in today’s old code would be solved if only the previous engineer…<insert solution here>. Unfortunately, wholesale rewrites lose valuable history, such as edge cases and bug fixes, and nearly always introduce new problems that aren’t present in the old code.

Even though old code is often viewed as time-wasting due to its complexity, new code doesn’t automatically solve for that. Old code was once new code, and new code will be old code shortly after it is written. The solution is to respect code as a constantly mutating organism, and continually shape it in ways that 1\ maintain its functionality and history, 2\ solve new problems, and 3\ improve its future mutability.

Following this practice, your code will gain usability and extensibility changes as needed, and will continue to function as new features are added. Rewriting old code will take you 6-18 months, and leave you back where you started, albeit with slightly newer “old code.”

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

“There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong.”