Escaping the rewrite spiral
Every engineer knows the pull of the clean slate. A field guide to telling the honest rewrite apart from the procrastination cosplay.
Twice in my career I've watched a team vanish into a rewrite and emerge, a year later, with software that did less than what it replaced. Both times, the rewrite felt righteous on day one. Here's the checklist I now run before touching the big red button.
The three honest reasons to rewrite
- The platform is dead. Not old — dead. Security patches have stopped; hiring is impossible.
- The model is wrong. The core domain abstraction actively fights every feature. Not "I'd have designed it differently" — actually wrong, proven by a trail of contorted workarounds.
- You've already strangled it. Half the system has migrated to the new pattern and the old core is a shrinking island.
The dishonest reasons (a partial list)
- The current code is embarrassing (it's fine; everyone's is).
- New framework enthusiasm wearing a business case as a costume.
- Estimating the rewrite against the current codebase instead of against the decade of edge cases it encodes.
That last one is the killer. The legacy system isn't big because the authors were fools. It's big because it knows things — every weird if is a scar from a real incident, a real client, a real Tuesday everything broke.
The middle path
Strangle, don't burn: route new features through a clean seam, migrate old ones opportunistically, and keep shipping the whole time. It's slower-feeling and faster-in-fact, which describes most good engineering decisions I know.