The Seduction of the Blank Slate
Every few months, I watch it happen again. A company — usually one that's been growing steadily for years on a system that actually works — holds a meeting where someone says the magic words: "We should just rebuild it from scratch." The room nods. Engineers get excited. Leadership sees a clean slate. And just like that, the company signs its own death warrant. Not literally, of course. But the next 18-36 months of pain, budget overruns, and missed market opportunities? Those are coming. They just don't know it yet.
I've seen this movie enough times to know exactly how it ends. And it almost never ends with a triumphant launch of a shiny new system that does everything the old one did, but better. It ends with a bloated, half-finished replacement that's missing features nobody thought to document, a demoralized team, and a quiet admission that maybe the old system wasn't so bad after all.
Joel Spolsky Was Right in 2000 — and He's Still Right
In April 2000, Joel Spolsky wrote what might be the most important essay in software engineering history: "Things You Should Never Do, Part I." His thesis was brutally simple: rewriting code from scratch is the single worst strategic mistake that any software company can make. He used Netscape as his cautionary tale — a company that decided to rewrite its browser from the ground up, spent three years doing it, and handed the market to Internet Explorer in the process. Netscape never recovered.
Spolsky's core insight wasn't about code quality. It was about knowledge. That "ugly" legacy codebase everyone wants to throw away? It contains years of accumulated bug fixes, edge case handling, and hard-won lessons about how the real world actually works. Every weird conditional, every seemingly unnecessary check, every hack that makes a senior engineer cringe — there's a reason it's there. Usually because a customer hit a problem in production and someone fixed it at 2 AM. When you throw that code away, you throw away all that institutional knowledge. And you will rediscover every single one of those edge cases the hard way.
The Numbers Are Brutal
If the philosophical argument doesn't convince you, the data should terrify you. McKinsey's research on large-scale IT projects found that 17 percent of IT projects go so badly that they threaten the very existence of the company. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Those aren't rounding errors. Those are existential numbers for small and mid-sized businesses.
The Standish Group's CHAOS Report has been tracking IT project success rates for decades, and the findings are consistently damning. Only about 29 percent of IT projects are considered successful — delivered on time, on budget, and with satisfactory results. The rest are either "challenged" or outright failures. And those numbers get worse as project size increases. Large projects — the kind that full rewrites inevitably become — have a failure rate approaching 70 percent.
Now combine those statistics with the specific dynamics of a rewrite. You're not building something new with clear requirements. You're trying to replicate something that already exists — something whose full scope nobody actually understands. That's a recipe for disaster baked right into the project charter.
Why Rewrites Always Take Longer Than You Think
There's a predictable pattern to every rewrite I've witnessed:
- Month 1-3: The team is energized. They're making incredible progress. The new architecture is clean, the code is beautiful, and everyone is convinced they'll be done ahead of schedule.
- Month 4-8: Progress slows. The team starts discovering features in the old system that nobody documented. Integrations that nobody mentioned. Business rules that live in the heads of employees who've been there for a decade. The scope grows.
- Month 9-15: The old system is still running in production, still accumulating new features and fixes. The rewrite team is now chasing a moving target. The gap between what the new system does and what it needs to do isn't closing — it's widening.
- Month 16+: Leadership starts asking uncomfortable questions. The budget is blown. The timeline has been revised three times. Someone suggests launching with a "reduced feature set." This is the moment you know the project is in trouble, because that "reduced feature set" means your customers are about to lose capabilities they depend on.
Basecamp's Jason Fried and David Heinemeyer Hansson have argued that the impulse to rewrite is usually an emotional response, not a rational one. Engineers look at old code and feel disgust. That disgust gets dressed up as a technical argument, but it's really an aesthetic preference masquerading as engineering judgment.
The Strangler Fig Pattern: Boring, Unglamorous, and Almost Always Right
The alternative to a ground-up rewrite is incremental modernization, most famously described by Martin Fowler as the Strangler Fig pattern. The concept is simple: instead of replacing the old system all at once, you gradually build new functionality around it, routing more and more traffic to the new components until the old system can be safely decommissioned.
Nobody gets excited about the Strangler Fig pattern. There's no dramatic unveiling. No big-bang launch. It's boring, methodical work. And that's exactly why it succeeds.
Here's what incremental modernization gives you that a rewrite doesn't:
- Continuous delivery of value. You're shipping improvements to production every sprint, not asking the business to wait 18 months for a system that might never arrive.
- Risk containment. If one component of the modernization goes sideways, you've lost weeks, not years. The old system is still there, still working.
- Knowledge preservation. You're migrating functionality piece by piece, which forces you to actually understand what each component does before replacing it.
- Team morale. Engineers stay motivated when they're shipping real work, not grinding on a project that feels like it will never end.
- Market responsiveness. Your business can keep evolving while modernization happens in the background, instead of freezing all innovation for the duration of a rewrite.
When Is a Rewrite Actually Justified?
I'm not an absolutist. There are rare cases where a rewrite makes sense. But the bar should be extraordinarily high:
- The technology platform is truly dead. Not "old" — dead. As in, you literally cannot hire developers, the vendor has ceased support, and there are no migration paths.
- The system is small enough to rewrite in weeks, not months. If your entire application can be rebuilt by a small team in a single quarter, the risk calculus changes.
- The fundamental architecture is incompatible with survival. If your system physically cannot scale to meet demand and there's no path to make it scale, you may not have a choice.
Notice what's NOT on that list: "the code is messy," "we don't like the framework," or "we'd do it differently if we started today." Those are not reasons to rewrite. Those are reasons to refactor.
The Real Problem Is Cultural, Not Technical
Here's what nobody wants to admit: the desire to rewrite from scratch is almost never about the software. It's about the organization. Companies that end up with unmaintainable systems got there through years of underinvesting in engineering discipline — skipping tests, ignoring code reviews, not refactoring, piling feature on top of feature without ever paying down technical debt. The codebase didn't become a mess overnight. It became a mess through hundreds of small decisions to take shortcuts.
A rewrite doesn't fix the culture that created the problem. If the same team, with the same processes, the same deadline pressure, and the same unwillingness to invest in quality builds the new system — you'll be right back where you started in five years. Except now you'll have spent millions of dollars to get there.
The hard work isn't building a new system. The hard work is building the discipline to maintain a system well over time. That means investing in automated testing. That means allocating time for refactoring in every sprint. That means treating technical debt like real debt — something that accrues interest and eventually comes due.
The Bottom Line
The replatforming trap catches smart people every day. The old system looks like a mess. A fresh start feels like freedom. The new architecture looks beautiful on a whiteboard. But whiteboards don't ship products. Joel Spolsky identified this trap twenty-five years ago, McKinsey's data has confirmed it repeatedly, and the failure rate of large IT projects continues to hover around 70 percent. The evidence is overwhelming and unambiguous.
Stop romanticizing the blank slate. The most valuable code in your organization isn't the code you'll write tomorrow — it's the ugly, battle-tested code that's running in production right now, handling edge cases you've already forgotten about. Modernize it. Don't destroy it. The Strangler Fig pattern — methodically replacing components while keeping the lights on — will get you to the same destination with a fraction of the risk. It's slower. It's less exciting. And it's almost always the right call.
-Rocky
#Replatforming #SoftwareDevelopment #DigitalTransformation #LegacySystems #TechnicalDebt #SMB #Engineering #EngineeringDreams
