The oldest piece of software advice that still causes arguments is Spolsky’s rule about rewriting from scratch. Twenty-five years on, teams still do it, still regret it, and still describe the regret in the same three ways. This is a note on how to tell, before you start, which category you’re in.
The incremental refactor
You leave the codebase where it is and change it in place. A new module replaces an old one behind the same interface. Tests run throughout. The lights never go out.
This is the right answer about 70 percent of the time. It is slower than it looks from the outside, faster than a rewrite from the inside, and produces a codebase that improves continuously rather than in one dangerous leap.
The parallel build
You start a new implementation alongside the old one. Traffic migrates piece by piece. At each step, both systems work; at each step, you can roll back. The old system stays alive until the new one has carried 100 percent of production traffic through at least one full business cycle.
Expensive but viable. The right answer about 25 percent of the time — specifically when the old system’s internal model is so wrong that new features keep costing ten times what they should, and when the team has the appetite to maintain two things at once for six to eighteen months.
The clean-room rewrite
You declare the old system obsolete. You stop feature work on it. A new team (or the same team, reassigned) builds the replacement from scratch. At some future date, you switch over.
The right answer approximately never. I can count the successful clean-room rewrites I have personally witnessed on one hand with fingers left over. The failure mode is always the same: the new system reaches 80 percent of the old one’s feature set, the team runs out of political capital, and the business reverts — leaving you with two systems where you used to have one.
The siren song of the clean-room rewrite is that the first six months feel wonderful. The code is new, the meetings are productive, the diagrams are clean. Every rewrite is a beautiful garden for a little while.
The diagnostic
When someone proposes a rewrite, I ask three questions. In order.
- Can you name the specific interface that’s wrong? If the answer is a gesture — “the whole thing” — that’s a signal to refactor in place, not rewrite. The dissatisfaction is aesthetic, not structural.
- What’s the smallest scope that contains the problem? If the problem lives in one service, rewrite that service. If it lives in a data model, rebuild the model with a migration plan. Only if the problem is genuinely at the level of “we chose the wrong framework” does the scope expand.
- What does the six-month P&L look like with both systems running? If the team can’t afford to support both for at least two quarters, they can’t afford the rewrite.
Most proposals die honestly on the second question.