28 December 2025 · 2 min
I used to always want to rewrite my code. Maybe even use another programming language. « If only I could rewrite my code, it would be so much better now. »
If you maintain software projects, you see it all the time. Someone new comes along and they want to start rewriting everything. They always have subjective arguments: it is going to be more maintainable or safer or just more elegant.
If your code is battle tested… then the correct instinct is to be conservative and keep your current code. Sometimes you need to rewrite your code : you made a mistake or must change your architecture. But most times, the old code is fine and investing time in updating your current code is better than starting anew.
The great intellectual Robin Hanson argues that software ages. One of his arguments is that software engineers say that it does. That’s what engineers feel but whether it is true is another matter.
« Before Borland’s new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material? » (Joel Spolsky)
Daniel Lemire, "Don’t be so eager to rewrite your code," in Daniel Lemire's blog, December 28, 2025, https://lemire.me/blog/2025/12/28/dont-be-so-eager-to-rewrite-your-code/.
[BibTeX]
I really love the Joel Spolsky quote about the Dodge Dart. We often treat code like a physical machine that wears out, but logic doesn’t actually decay. I have seen so many teams throw away years of bug fixes and edge-case handling just because the syntax looked a little dated to a new hire.
It’s not that code rusts it’s that it grows over time. Small decisions that lead to complexity or duplication accumulate. As complexity increases the odds of introducing new bugs increases. As duplication increases the odds of fixing bugs decreases. Refactoring code is meant to reduce complexity or duplication and tests are the spec that ensure edge cases aren’t mixed. Age is a metaphor just like technical debt.
Daniel, I think this post straddles ambiguity by using the words “rewrite code” instead of “greenfielding” and “refactoring” or otherwise being more precise. The takeaway, which I 100% agree with, is,
“But most times, the old code is fine and investing time in updating your current code is better than starting anew.”
CJ’s response sounds more like refactoring, since it implies “syntax” was improved, done with poor test coverage.
P.S. Thank you for sharing your thoughts via your blog. I’ve been following for years.
Thanks Nathan.
Good reasons for rewriting code are: original design assumption are no longer true (e.g. Y2K), product requirements evolve (e.g. users switching from desktop to mobile web), dependencies change or are no longer supported. With that said, most of these problems can be solved by strategically rewriting limited parts of an application with lower risk than a complete rewrite.
Luiz Barroso has an excellent essay titled Innovate Within that has the same conclusion https://fontoura.org/papers/barroso.pdf