esc
Being riclib

The Rewrite Trap

The software industry has a dirty secret: it rewrites everything every twelve years, learns nothing from the rewrite, and does it again. I've watched this cycle from three angles — as a developer,...

March 22, 2026

The software industry has a dirty secret: it rewrites everything every twelve years, learns nothing from the rewrite, and does it again.

I’ve watched this cycle from three angles — as a developer, as a consultant, as someone who’s been in the room when a telco decides to replace its billing system for the third time. The cycle is so predictable it should be in a textbook. It isn’t in a textbook because admitting the cycle exists means admitting that the last rewrite was not, in fact, the one that fixed things.

It never is. Here’s why.

The Code Cycle: Twelve Years of Forgetting

Years 1–3: Build fast. Ship features. Accumulate complexity. Call it “moving fast.” The codebase grows. The architecture makes sense to the people who built it. The onboarding doc says “ask Sarah.”

Years 4–6: Sarah left. The codebase still grows. Features slow down. New developers take months to become productive. The architecture makes sense to nobody — not because it’s bad, but because the reasons behind each decision left with the people who made them. The billing retry has a 7-second backoff. Nobody knows why. It’s because the upstream gateway returns a false positive at 5 seconds and the postmortem from Year 2 is in nobody’s Confluence but was in everyone’s muscle memory until everyone left.

Years 7–9: Someone proposes a rewrite. A new team is assembled. They study the old system’s problems — they can see those. The slow queries. The spaghetti module. The deployment that takes four hours. They do not study the old system’s qualities — they can’t see those. The 7-second backoff. The edge case in invoice rounding that handles three currencies correctly. The retry logic that looks wrong but prevents a race condition discovered in production in Year 3.

Years 10–12: The rewrite ships. It’s clean. It’s fast. It’s modern. It handles the problems the old system had. It does not handle the problems the old system had solved. The 7-second backoff is now 3 seconds (the default). The gateway false positive returns. The billing errors start. The race condition resurfaces.

The clock resets.

Joel Spolsky wrote about this in 2000 — “Things You Should Never Do” — using Netscape as the cautionary tale. Netscape rewrote their browser from scratch. The rewrite took three years. During those three years, Internet Explorer ate their market share. The rewrite shipped. It had new problems. Netscape died.

That was twenty-six years ago. The industry read the essay, nodded, and kept rewriting.

Why the Rewrite Always Fails

The rewrite fails because it’s a Gall’s Law violation at industrial scale.

Gall’s Law says: a complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works.

The rewrite team is designing a complex system from scratch. Yes, they’re “informed by” the old system. But they’re informed by the old system’s visible properties — the architecture diagrams, the API contracts, the database schema. The old system’s invisible properties — the decisions, the workarounds, the edge cases, the muscle memory — are not in the documentation. They were in the people. The people are gone.

The rewrite team has the old system’s skeleton. They don’t have its nervous system.

The Technical Debt Mislabel

Here is where the vocabulary fails us.

When the straitjacket tightens — when features slow, when onboarding takes months, when the codebase feels heavy — the industry reaches for a term: technical debt. The code owes something. The debt must be paid down. Either we pay it incrementally (refactoring sprints) or we declare bankruptcy (rewrite).

But the code doesn’t owe anything. The code taught something.

Every complex system in a working codebase is in one of two states. It is either tuition — you’re still learning from it, the complexity is paying for understanding — or it is weight — you’ve learned everything it has to teach, and the simple replacement is visible.

When you call tuition “technical debt,” you create two bad options: ignore it (the straitjacket tightens) or rewrite it (you lose the understanding). Both fail because both misidentify what the code is.

The code is not a debt. The code is a diploma. The question is not “how do we pay this down?” The question is “what did we learn, and can we build something simpler now that we know?”

The Third Option

There is a third option that neither “ignore” nor “rewrite” considers: liberate.

Keep the understanding. Delete the code. Build the simple system that the complex one taught you.

Not a rewrite — a transmutation. The new system doesn’t reproduce the old system’s architecture. It doesn’t fix the old system’s problems. It solves the same needs with the understanding that only comes from having built, operated, and lived inside the complex system for years.

This requires one thing that rewrites don’t: the same people. The people who built the complex system. The people who know why the backoff is 7 seconds. The people who carry the Discovery Tax receipts in their heads.

Last week I replaced five interconnected systems — a draft store, a pub/sub bridge, an event publisher, a streaming buffer, a render handler — with forty lines. Same features. Better capabilities. The five systems were 650 lines of code. They had taken four months to build. They were not wrong. They were tuition.

I could not have written the forty lines without building the 650 first. Each system taught exactly one discovery. The forty lines are the union of all five discoveries. The five systems were the price of admission. The forty lines are the diploma.

This is what I call Liberato’s Law: the simple system that replaces N complex systems requires building all N first. You can’t skip the tuition. You can’t skip ahead to the diploma. But you can — you must — graduate.

The AMOS Cycle: Twelve Years of Outsourcing

The code cycle has a twin: the organizational cycle. I’ve watched this one in telcos, banks, and insurance companies. It runs on the same clock.

Phase 1: “IT is too expensive. It’s not our core business.” The board approves outsourcing. Capital expenditure becomes operational expenditure. The CFO is pleased.

Phase 2: The internal team is dismantled. Some join the vendor. Most leave the industry, or the country, or both. The understanding — the 7-second backoff, the invoice rounding, the race condition — walks out the door in cardboard boxes.

Phase 3: The vendor’s A-team wins the contract. The A-team builds the transition. The A-team moves to the next sale. The B-team maintains. The B-team has runbooks. Runbooks are not understanding. Runbooks are recipes without taste.

Phase 4: Change requests are billable. The system fossilizes. Innovation requires a change request. The change request requires a quote. The quote requires a scope document. The scope document requires a meeting. The meeting is in four weeks. The feature ships in six months. Or doesn’t.

Phase 5: “The vendor is too expensive and nothing improves.” An RFP is issued. A new vendor promises transformation. The grass is greener. The new vendor’s A-team studies the old vendor’s deliverables. The old vendor’s understanding is not in the deliverables. The old vendor’s A-team left three years ago.

Phase 6: “Nobody understands our systems.” The board approves insourcing. A new internal team is hired. They have zero institutional memory. The twelve-year clock resets.

Each handoff — internal to vendor A, vendor A to vendor B, vendor B to internal — is a forced Gall’s Law violation. Each new team designs from their understanding of the visible system. The invisible system — the one that actually works, the one that handles the edge cases, the one that knows about the 7-second backoff — dies at each handoff.

The Discovery Tax was paid by the original team. The receipts left in their heads. You can’t outsource receipts that live in people’s heads.

The Lean Startup Missed Step

Eric Ries got it almost right. Build → Measure → Learn is the correct loop. The MVP is the correct vehicle. The pivot is the correct response to learning.

But the loop is missing a step. It should be: Build → Measure → Learn → Simplify.

The simplification is the step where you take everything you learned from the complex system and build the simpler one that the complex one taught you. Not a pivot — pivots change direction. A liberation — liberations change altitude. You go from 650 lines to 40 lines. Same direction. Less weight.

Without the simplification step, the loop becomes: Build → Measure → Learn → Build More → Measure → Learn → Build More. The system accumulates. The learning compounds. But the code never gets simpler. The understanding grows but the codebase grows faster. Eventually the understanding can’t keep up. The straitjacket arrives.

Mem is the cautionary tale. Mem 1.0 was paying its tuition — features arriving, the flow improving, organisational tools appearing. The system was accumulating the understanding that would have enabled Mem 2.0 to be simpler and more capable.

Instead, Mem 2.0 removed the features. Not simplified them — removed them. Threw away the tuition before graduating. Pivoted to “AI-first” without the understanding of what “notes-first” required. The qualities that made 1.0 approaching-useful were sacrificed. The problems that 1.0 had identified were solved by deletion instead of by liberation.

Evernote is the opposite pathology: never simplified. Seventeen years of features. No pruning. No tending. The elephant remembered everything except how to get lighter. Critical mass. The straitjacket that no acquisition, no new CEO, no redesign could loosen — because loosening requires deleting, and deleting requires understanding what to keep, and understanding requires the people who built it, and those people are on Year 14 of a twelve-year cycle.

Two failure modes. Same missing step.

The Two-Year AI Cycle

And now the cycle is accelerating.

Companies are looking at what AI can do — write code, maintain systems, answer questions, generate documentation — and concluding they don’t need the humans. The humans are expensive. The AI is cheap. The math is obvious.

The math is wrong.

The AI is the fastest typist in history. It writes four thousand lines of code in a day. It does not know why the billing retry has a 7-second backoff. It does not know that the invoice rounding handles three currencies. It does not carry the Discovery Tax receipts. It types fast and understands nothing.

When you fire the developers and keep the AI, you are outsourcing to a vendor with infinite typing speed and zero institutional memory. This is the AMOS cycle at light speed:

Month 1: “AI can do the developers’ work.” The developers are laid off. The AI maintains the code. The AI is fast, confident, and productive.

Month 6: The system drifts. The AI modifies code it doesn’t understand. Changes are locally correct and globally wrong. The 7-second backoff becomes 3 seconds because 3 is the default and the AI doesn’t know about the postmortem from Year 2. The billing errors start.

Month 12: “The AI codebase is unmaintainable.” Developers are hired. They have zero institutional memory. The fired developers have moved on. The institutional memory is gone. The clock resets.

Month 24: The cycle completes. Two years instead of twelve.

The twelve-year outsourcing cycle at least gave you time to notice. The AI cycle compresses the same pathology to months. By the time you realise the understanding is gone, the people who had it are gone too.

The cruelest irony: the AI is the best possible argument for keeping the humans. The AI multiplies the humans’ understanding. A developer who knows where the stones are can direct the AI to plant four thousand seeds a day without hitting a single stone. That’s a 100x multiplier.

Fire the developer. The AI plants four thousand seeds a day into stones. 100x times zero understanding is zero.

The Prescription

Three cycles. Same law. Accelerating clock.

The code cycle: build → straitjacket → rewrite → repeat (12 years).
The AMOS cycle: insource → outsource → re-outsource → insource (12 years).
The AI cycle: humans → AI → “where did the understanding go?” → humans (2 years).

Same root cause in all three: treating understanding as a byproduct instead of the product.

The code is not the asset. The vendor contract is not the asset. The AI’s output is not the asset. The understanding is the asset. Everything else is a receipt.

The prescription is not complicated. It’s just unpopular:

Keep the people who paid the Discovery Tax. They are the only ones who can build the simple system. They are the only ones who know why the backoff is 7 seconds. They are the only ones who can direct the AI without hitting stones.

Simplify instead of rewriting. Take what the complex system taught you and build the forty lines. Not a new team. Not a new vendor. Not an AI replacement. The same people, building the simpler thing that only they can see because only they paid the tuition.

Budget for the Discovery Tax. It will be paid whether you budget for it or not. The question is whether you cash the receipt (build the simple replacement) or throw it away (rewrite from scratch, outsource to a new team, fire the developers and hope the AI figures it out).

The industry will not take this prescription. The industry will rewrite. The industry will outsource. The industry will fire developers and replace them with AI. The twelve-year clock will tick. The two-year clock will tick faster.

And somewhere, a developer who was fired because “AI can do your job” will be hired back — at a higher rate, with less context, to fix the problems that only they could have prevented.

The hamster wheel turns. The door was always open. The hamster doesn’t know, because the hamster that knew was fired.

There’s an encyclopedia where software principles get the roast they deserve — Liberato’s Law in a tax office, Gall’s Law in a boardroom, The Discovery Tax on a receipt nobody kept. And a mythology where these ideas have been arguing with each other for a hundred episodes.

See also: