Every engineer, looking at a messy codebase, has the same fantasy: throw it all away and rewrite it clean. It feels obviously right. It's also, according to one of the most famous essays in software, one of the most reliable ways to kill a company. Netscape did exactly this, and handed the browser market to Microsoft.
Key Takeaways
- Netscape rewrote its browser from scratch (4.0 to 6.0), took ~3 years with no competitive releases, and lost the market to Internet Explorer (Joel Spolsky).
- The "ugly" old code usually encodes years of hard-won bug fixes you'll silently re-introduce (Joel Spolsky).
- A rewrite freezes your product while competitors keep improving theirs.
- Incremental refactoring almost always beats a from-scratch rewrite.
The Cautionary Tale
In his landmark essay "Things You Should Never Do," Joel Spolsky argued that a working application should never be rewritten from the ground up, and he used Netscape as the corpse (Joel Spolsky). After version 4, Netscape threw away its codebase and started over. The rewrite took about three years, and during that time they couldn't meaningfully improve the browser people were actually using. Internet Explorer, free, bundled with Windows, and continuously improved, ate their market share to almost nothing. Netscape never recovered.
Spolsky's core insight is about what that messy old code actually is. Those crufty, weird-looking functions you want to delete are often bug fixes. Each ugly conditional is usually a corner case someone hit in production and patched. Throw the code away and you throw away years of accumulated, undocumented knowledge, then get to rediscover every one of those bugs the hard way (six rewrite stories).
Why the Second System Is Dangerous
There's an older name for part of this: Fred Brooks's "second-system effect." The second version of a system is the most dangerous one a person designs, because they pour in every idea they cautiously left out of the first, and over-build it. A rewrite is almost always a second system, so it tends to arrive late, bloated, and full of the ambition the constraints of the first version wisely suppressed. You set out to fix the mess and build a bigger, later one.
| The rewrite fantasy | The rewrite reality |
|---|---|
| Clean slate, no cruft | Re-introduce old fixed bugs |
| Faster once it's done | Years with no product progress |
| Simpler design | Second-system over-engineering |
| Competitors wait | Competitors gain the whole time |
A Concrete Version
A team inherits a five-year-old codebase everyone hates and convinces leadership to rewrite it clean, "six months, then we'll move faster." Eighteen months later the rewrite still doesn't have feature parity, because the old system did a hundred small things nobody documented. The whole time, the old product got almost no improvements, and a competitor shipped the feature customers were asking for. The rewrite finally lands, buggy in new ways, and the team is further behind than when it started. This is the Netscape story at startup scale, and it plays out constantly.
The Honest Counterpoint
"Never" is too strong, and taken literally it's its own trap. Sometimes the platform is genuinely dead (an unsupported language, a framework with no security patches), or the original architecture truly can't support where the business needs to go, and a rewrite is the right, if painful, call. The honest rule isn't never. It's that rewrites are far riskier and more rarely justified than engineers' instincts suggest, and the default should be incremental: refactor the messy code in place, strangle the old system piece by piece behind a stable interface, and keep shipping the whole time. Choose a full rewrite only with clear eyes about the Netscape-shaped risk.
What This Means for Teams
Knowing when to refactor versus rewrite is one of the highest-stakes judgment calls in engineering, and it's exactly the hard-won judgment that separates senior engineers from confident-but-green ones, the same instinct behind resisting premature microservices. An experienced engineer has usually watched a rewrite go sideways and will push for the incremental path that keeps you shipping, which is part of what we screen for in how to verify a senior engineer. See available engineers.
Frequently Asked Questions
Why do software rewrites fail so often?
The old code encodes years of undocumented bug fixes you'll re-introduce, and a rewrite freezes your product while competitors keep improving. Joel Spolsky's classic example is Netscape, whose from-scratch rewrite cost it three years and the browser market.
What is the second-system effect?
Fred Brooks's observation that the second version of a system is the most dangerous, because designers over-build it with every idea they left out of the first. Rewrites are usually second systems, so they tend to arrive late and bloated.
Should I ever rewrite from scratch?
Rarely, and only with clear eyes. It can be right if the platform is truly dead or the architecture genuinely can't support the business. Usually incremental refactoring, strangling the old system piece by piece, is safer.
What's the alternative to a rewrite?
Refactor in place and use the "strangler" approach: build the new behind a stable interface and replace the old piece by piece while continuously shipping, so you never freeze the product.
The Bottom Line
The urge to throw away messy code and start clean is nearly universal and nearly always a mistake. Netscape's rewrite cost it three years and the market, because old code carries hard-won knowledge and a rewrite freezes progress while rivals advance. Refactor incrementally, keep shipping, and treat a full rewrite as a rare, clear-eyed exception, not the default.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
