The Temptation of the Rewrite
Imagine you inherit a 15-year-old application. It was built by people who have long since left the company. It runs on an outdated framework, has no automated tests, and every time someone changes one part, something unrelated breaks. The codebase is what engineers call a "monolith" — a single, large application where everything is tangled together.
The temptation is always the same: "Let's just throw this away and rewrite it from scratch!"
This is known as a "Big Bang Rewrite" — you stop all work on the old system, spend months (or years) building a shiny new replacement, and then flip a switch to cut over. In theory, it sounds liberating. In practice, it is one of the most reliably catastrophic decisions in software engineering.
Here's why Big Bang rewrites fail:
- Time dilation. The rewrite always takes 2-3x longer than estimated. The original system accumulated 15 years of business logic, edge cases, and undocumented behaviors. Your rewrite team rediscovers each one the hard way.
- Feature freeze paralysis. While the rewrite is underway, the business still needs new features. But you can't add them to the old system (it's being replaced) or the new system (it's not ready). The business stalls.
- The moving target. The old system doesn't stand still. Bug fixes, regulatory changes, and urgent patches keep happening, and the rewrite team must constantly chase a moving target.
- The second system effect. Fred Brooks described this in The Mythical Man-Month: teams building a replacement tend to over-engineer it, cramming in every feature they wished the old system had, bloating scope beyond recognition.
Netscape's rewrite of their browser in the late 1990s is the canonical cautionary tale. It took three years, during which Internet Explorer captured the market. Joel Spolsky called it "the single worst strategic mistake that any software company can make."
There must be a better way to modernize without stopping the world.
Key Point: The Big Bang Rewrite fails not because the new technology is wrong, but because it underestimates the accumulated knowledge embedded in the old system. Every line of legacy code, no matter how ugly, represents a decision that solved a real problem. Replacing it all at once means re-learning all those decisions simultaneously under deadline pressure.