The rewrite that worked

The rewrite that worked was scoped to what one team could hold in their heads, shipped something to production in its first quarter, and never enjoyed a moment of executive glamour. The rewrites that failed had a code name and a kickoff party. This is close to a natural law, and it is worth asking why.

Define the term first, because "rewrite" covers three different projects. There is the port (same behavior, new substrate), the redesign (new behavior, and the old system was merely the excuse), and the true rewrite (same responsibilities, rebuilt because the original can no longer accept change safely). The port is a logistics problem. The redesign is a product bet wearing engineering clothes. Only the third deserves the famous warnings, and the famous warnings exist because the third is usually attempted as if it were the first.

The failure mechanism is well documented and almost boring: the old system keeps moving while the new one is built, so the new one chases a target that accelerates away from it. Every month of parallel development adds features to reimplement, edge cases to rediscover, and stakeholders who preferred the old bug. The second system arrives, in Brooks's phrase, over-designed and late, and the cutover becomes a cliff because nobody planned for the two systems to coexist.

The rewrites that work refuse the cliff. Martin Fowler gave the pattern its name in 2004, after a fig that germinates in a host tree's canopy: the strangler fig. Route by route, job by job, the new system takes traffic while the old one keeps the lights on, and there is never a day when everything must go right at once. The pattern is old, unglamorous, and undefeated. What it costs is patience and a routing layer; what it buys is the ability to be wrong in small, reversible amounts.

I watched a payments team spend eleven months this way, moving one transaction type at a time behind a proxy, running old and new in parallel and diffing the ledgers nightly. The final cutover was a non-event announced in a stand-up. Nobody wrote a conference talk about it, which is precisely the review this journal would give it: five stars, nothing to report.

There is a leadership component that the pattern literature understates. A strangler migration produces no single moment of triumph, so it must be defended quarterly against people who want one. The teams that finish keep a visible ledger: percent of traffic moved, decommission dates hit, incident counts on old versus new. The teams that get cancelled kept their progress in the repository, where finance cannot see it.

The uncomfortable conclusion is that rewrite success is mostly scoping discipline, which is to say mostly saying no. No to the redesign smuggled in ("while we're in there"), no to the second team's pet subsystem, no to the cliff. The original system took years to grow its complexity the slow way. The rewrite that works pays that complexity down on the same installment plan, just at a better interest rate.