Deep Dive
The Forgotten Law: Why Rewrites Were Always a Disaster
Lunduke opens with a sharp observation: experienced programmers from the 80s, 90s, and early 2000s learned a painful lesson — rewriting working code from scratch is a near-guaranteed disaster. He quotes Joel Spolsky's foundational 2000 essay Things You Should Never Do Part One, which used Netscape's failed rewrite of version 6.0 as the canonical example of this mistake. Netscape had a three-year gap between version 4.0 and the failed 6.0 rewrite, during which they bled market share while competitors moved forward. Spolsky also cited Borland's attempt to turn Arago into dBase for Windows and their rewrite of Quattro Pro — both killed the company while Microsoft Access and Excel ate their lunch. Even Microsoft nearly made this error with Project Pyramid, a complete Word rewrite that was shelved and forgotten. The through-line: companies that made this choice lost years of development time and handed competitors a gift of two or three years to capture market share.
The Psychology of Programmer Impatience
Spolsky nailed the psychological root of rewrites: programmers are architects at heart and want to bulldoze and rebuild rather than incrementally improve. But his deeper insight is the reason they think the old code is a mess — it's because reading code is fundamentally harder than writing it. This asymmetry means every programmer thinks they could write it better and cleaner. They see a two-page function and think it's bloated garbage, not recognizing that each seemingly random line is a bug fix earned through production disaster. One line fixes Nancy's Internet Explorer crash. Another handles low-memory conditions. A third deals with floppy disc eject failures mid-load. Another ensures Windows 95 compatibility. Each took weeks of real-world usage to discover and days to debug and fix. When you throw out that function and rewrite it, you're not simplifying — you're starting a debt clock where those bugs will be rediscovered one by one in production.
Ubuntu's Active Disaster in Real Time
Lunduke uses Ubuntu as a live case study of this exact mistake playing out in 2024. Ubuntu held market dominance in Linux for years with stable, working code carrying decades of optimization and edge-case fixes. Yet Ubuntu's engineering leadership decided to rewrite massive chunks in Rust, a language still incomplete, using predominantly part-time developers new to the project. The catastrophe is compounded by Ubuntu's release cadence: they ship every six months and push daily repository updates. Unlike the 1990s when software shipped as a monolith on CD, Ubuntu is shipping brand-new, untested rewritten code into production continuously. Users aren't waiting for a polished release — they're getting raw, broken, not-yet-tested code and told to deal with it. This creates a reputation not for slow shipping but for shipping garbage. Lunduke argues this is monumentally worse than the Netscape scenario because there's no grace period to stabilize; the broken code hits users immediately.
Management's Role: Stopping the Impulse
Lunduke shifts into personal experience as an engineering manager. He notes that even talented developers had an irrepressible urge to throw out working code and start fresh — it was his job to stop them. He'd tell teams no, work on the existing code, find ways to optimize and improve it incrementally, but rewrites weren't happening. He quotes Steven Sonowski, former head of Windows at Microsoft, who said project managers exist to prevent developers from happily spending years retyping all code using new tools and proper indentation. The current problem is that today's engineers and engineering managers lack the gray-haired authority figure to say no. Either they don't have the experience to know these lessons or they've forgotten them. There's no one above them saying we're not throwing out the core utilities, we're not throwing out pseudo and ls — heavens no. The industry has collectively forgotten the hard lessons of the 80s and 90s, and those lessons desperately need to be relearned.