Never rewrite was a budget rule

Every engineering leader can quote the rule. Don't rewrite. Joel Spolsky wrote it down in 2000, using Netscape as the corpse, and it has been the most reliable piece of advice in software architecture ever since. Mostly it has deserved that.

It was never a rule about software, though. It was a rule about money.

What the rule was actually pricing

Two bills arrive with any rewrite, and they are very different sizes.

The first is construction. Someone has to build the thing again, and for twenty-five years that meant human-years: a team, pulled off the roadmap, for two or three times however long they said it would take. That multiple was so consistent you could plan around it.

The second is rediscovery. The system you're replacing encodes years of accumulated correctness. The edge case nobody remembers. The one customer whose data is malformed in a specific way. The workaround for a vendor bug from 2023 that turns out to be load-bearing. A rewrite finds those one production incident at a time, and you pay for each one in trust rather than in salary.

The rule worked because bill one made bill two unbearable. You spent a year rebuilding, then spent a second year discovering what you'd forgotten, and by month eighteen someone senior was asking why the old thing still hadn't been switched off. Everyone has seen that happen. Nobody wants to be in it twice.

Bill one collapsed. Bill two didn't move.

An engineer on my team rewrote our entire CLI, a real production tool with real users, in a couple of days. No ceremony. No proposal, no steering group, no phased migration plan. It wasn't heroic and it wasn't a weekend hack. It was a Tuesday.

For that class of system, bill one is now closer to a rounding error than to a quarter. Five years ago I'd have argued for the slow refactor every single time, and I'd have been right to.

Bill two is exactly where it was. The old system still knows things nobody wrote down, and machine time doesn't recover them, because a model has the same access to your institutional memory that you do. Which is none.

The constraint moved rather than disappearing

Rewrites are cheap to build now and expensive to specify.

That's the whole shift, and it changes which question decides the call. It used to be whether you could afford to build the thing twice. Now it's whether you can say what it actually has to do.

Which means the rewrites that fail from here will fail for exactly the reason they always failed. Nobody knew what the old thing did. The difference is that this used to be one of two reasons, and cost was the one quietly stopping most bad proposals before the specification problem ever got its turn. Cost was doing a lot of unpaid work as a filter. It isn't doing it anymore.

So bad rewrites get cheaper to start and stay just as expensive to finish, and a lot more of them are going to get started. That's the real risk in front of most orgs right now, and it isn't the one they're bracing for.

How you earn it

Characterisation. Not a new idea, just newly load-bearing.

Before you replace anything, pin the current behaviour down as assertions. Not what the system was supposed to do. What it does. Every weird branch, every tolerated malformation, every response that would surprise you if you saw it in isolation. That happens to be work agents are unusually good at, because it's bounded, mechanical and checkable.

Do that and the rewrite stops being a leap of faith. It becomes a specification you either satisfy or you don't, with a test that tells you which. A team that can produce that specification has genuinely been handed something new. A team that can't hasn't been rescued by cheaper tooling. It's been handed a faster way to rediscover its edge cases in production.

So: rewrite, yes, if you know what you actually need. The conditional is doing all the work, and it always was.

The ceremony is now the expensive part

This is the part orgs get wrong even after they've accepted everything above.

Rewrite governance was priced for human-years too. The written proposal. The estimate nobody believes. The steering group, the phased migration, the explicit rollback plan, the decision point where you'd stop. All of it proportionate when the thing underneath was a two-year commitment of a team you couldn't get back.

Put that same apparatus around a two-day change and your process costs an order of magnitude more than the work it governs. You haven't been careful. You've made rewrites expensive again for reasons that have nothing to do with building anything, and the only thing the ceremony is protecting at that point is itself.

Size the process to the thing. A bounded component with characterisation tests and a flag in front of it needs one person's decision and an afternoon. A core system with three teams downstream still gets the memo.

What this doesn't license

Not everything is a CLI.

The systems where this reasoning holds are bounded, have a real interface, and behave observably from the outside. Tools. Services with an actual contract. Anything you could describe to a competent stranger in a page. That's a wider category than most people assume and it is not everything.

Where it doesn't hold is where the behaviour is the business. Your billing engine. Your core entities, which outlive every rewrite anyway. Anything where "what does this currently do" is a question your company would need three departments and a month to answer. Cost was never the binding constraint on those. Understanding was, and it still is.

The test isn't size. It's whether you can characterise it. If you can, the old rule has expired for that system. If you can't, the rule was never really about rewriting in the first place, and no amount of machine time is going to save you.