"Let's just rewrite it from scratch." Every engineer has said this at some point. The existing codebase is a mess. Nobody understands it. Surely starting fresh would be faster than continuing to work with this nightmare. But here is the uncomfortable truth: rewrites almost never deliver what they promise.
The Seduction of the Blank Slate
It is easy to see why rewrites are appealing. The existing code is full of historical decisions, workarounds, and accumulated complexity. A new codebase could be clean. Modern. Built with everything we have learned.
But this view fundamentally misunderstands what legacy code represents. That messy code is not just technical debt. It is also encoded knowledge. It contains solutions to problems you have forgotten existed. It handles edge cases that will bite you again if you do not handle them in the new system.
"The first rule of rewrites: the old code is ugly because it handles reality. The new code will eventually be just as ugly, or it will not work."
Why Rewrites Fail
We have seen many attempted rewrites. The pattern is remarkably consistent:
- Underestimated scope. The new system needs to do everything the old system does. Teams consistently underestimate how much the old system actually does.
- Moving target. While you rewrite, the business keeps moving. Features keep getting added to the old system. The new system is always chasing a moving target.
- Second system effect. Given a chance to start fresh, teams add complexity. "This time we'll do it right" leads to over-engineering.
- Integration nightmare. At some point, you need to switch from old to new. This transition is always harder than expected.
- Business pressure. Rewrites take years, not months. Eventually, the business loses patience and starts demanding features in the old system, splitting your team's attention.
The Alternative: Incremental Improvement
Instead of big bang rewrites, we advocate for incremental improvement. The approach:
- Strangler fig pattern. Build new functionality alongside the old system. Gradually route traffic to new components. Eventually, the old system has nothing left to do.
- Targeted refactoring. Identify the most painful parts of the existing system and improve them incrementally while keeping the system running.
- Continuous modernization. Upgrade dependencies, improve test coverage, and clean up code as part of normal development work.
When Rewrites Make Sense
There are rare situations where a rewrite is the right choice:
- The technology is genuinely obsolete and cannot be incrementally migrated.
- The system is so small that rewriting is genuinely quick.
- You are willing to accept significant feature regression during the transition.
- You have explicit business buy-in for the timeline and risks.
Even then, the safest approach is usually to break the rewrite into phases, maintaining the ability to stop and ship at any point.
Respecting the Old Code
The impulse to rewrite often comes from a place of disrespect for what exists. But that "terrible" legacy code has been running in production, serving customers, and generating revenue. It has survived reality.
Before dismissing it, try to understand it. Often, what looks like poor decisions were actually reasonable choices given the constraints at the time. And understanding those constraints will make you better at improving the system incrementally.
The boring truth is that steady improvement almost always beats revolution. It is less exciting, but it is far more likely to succeed.