When is a stream of small, continuous in-place improvements the right strategy for a decaying system, and when do you need a larger planned effort such as a Strangler Fig migration or a full rewrite? How do you decide?

## Framing the decision The real question is: **can a sequence of local, low-risk edits reach the problem?** - **Local pain** — bad names, duplicated blocks, long functions, missing tests, magic values. Each instance is independently fixable and each fix is independently valuable. → Boy Scout Rule / opportunistic refactoring. - **Structural pain** — the module boundaries are wrong, everything shares one mutable data store, the framework is end-of-life, the deployment unit forces the whole org to release together. No local edit improves this; you can polish every function in the system and still have the same architecture. → planned, funded intervention. A useful test: *if every file were individually beautiful, would the problem be gone?* If no, it's structural. ## The spectrum of interventions There are more than two options, and knowing the middle of the spectrum is what distinguishes a senior answer. 1. **Opportunistic cleanup (Boy Scout Rule)** — continuous, unfunded, zero-ceremony, targets whatever you touch. 2. **Scheduled/campaign refactoring** — a named, ticketed refactoring of one area, still behaviour-preserving, still incremental, but planned and estimated. 3. **Branch by abstraction** — introduce an abstraction over the thing you want to replace, build the new implementation behind it, migrate callers gradually (often behind a feature flag), then delete the old one. Keeps the system releasable throughout; avoids long-lived branches. 4. **Strangler Fig application** (named by Martin Fowler after the strangler fig, which grows around a host tree until the host dies) — put a façade/router in front of the legacy system, implement slices of functionality in a new system, redirect traffic slice by slice, and retire the old system when nothing routes to it. Each slice ships and earns value; you can stop or pause at any point. 5. **Big-bang rewrite** — build a full replacement in parallel, cut over once. Supporting technique: **parallel run** (dark launching) — send production traffic to both old and new implementations, serve the old result, and diff the outputs to verify equivalence before flipping. This is how you get confidence in a replacement when the specification is "whatever the old system does". ## Why big-bang rewrites usually fail Joel Spolsky's "Things You Should Never Do" (2000, on the Netscape rewrite) is the canonical reference; the mechanisms are worth naming individually: - **Feature parity treadmill.** The old system keeps getting features while you rebuild, so the target moves. You can be perpetually 90% done. - **Dual maintenance.** Every bug must be fixed twice, doubling cost during the longest, most stressful period. - **Encoded knowledge loss.** Ugly conditionals often *are* the requirements — accumulated fixes for real edge cases, regulatory quirks, a customer's odd data. "Nobody knows why this branch exists" means you're about to rediscover it in production. - **No incremental value.** Nothing ships until everything ships, so the effort is politically fragile: a leadership change, a budget cut, or one missed milestone kills it, and all invested work is lost. - **Second-system effect** (Fred Brooks, *The Mythical Man-Month*) — the replacement accumulates every feature the team wished they'd had, so it over-generalizes and is late. - **Same team, same forces.** If the pressures that produced the mess (deadlines, no tests, unclear ownership) persist, the new system rots on the same trajectory, just later. ## When a rewrite *is* the right call Be able to name real cases, otherwise the answer sounds dogmatic: - The **platform is dead**: unsupported runtime/framework with unpatched security holes, or hardware/OS no longer available. - **Small scope**: the component is a few thousand lines with a narrow, well-understood interface — rewriting is cheaper than archaeology. - **Parity is explicitly not required**: the business has decided the product should behave differently, so preserving old behaviour has negative value. - **The core model is wrong** in a way abstraction can't hide (e.g. a fundamentally single-tenant design that must become multi-tenant), *and* the system is small enough to replace. - **Economics dominate**: licensing or hosting costs of the old stack exceed the rebuild cost. Even then, prefer to execute the rewrite *incrementally* via Strangler Fig rather than as a cutover, unless the system is genuinely tiny. ## How to decide — a practical checklist 1. **Measure, don't feel.** Where is the cost actually incurred? Use hotspot analysis (change frequency × complexity), defect density per area, lead time and change-failure rate per component, and time-to-onboard. Decay you never touch costs little. 2. **Classify the pain**: local vs structural, per hotspot. 3. **Check reachability**: is there a sequence of behaviour-preserving steps from here to the target? If yes, prefer it. The **Mikado Method** is the explicit technique — attempt the change, note what breaks, revert, fix prerequisites first, building a dependency graph of small safe steps. 4. **Check the safety net.** Without tests, *no* strategy is safe; characterization tests and a parallel-run harness are prerequisites for either path. 5. **Check the ceiling.** If incremental work would take years to reach an acceptable state, or is blocked by an external constraint (EOL platform, compliance deadline), escalate. 6. **Check organizational stamina.** Long efforts need sustained sponsorship. If you can't guarantee 18 months of funding, choose the strategy that delivers value in slices — which is an argument *for* Strangler Fig and *against* big-bang. 7. **Fix the forces, not just the code.** Whatever you choose, if the root cause was no tests, no ownership, or no time, address that too — otherwise you'll be here again. ## Where the Boy Scout Rule sits Even during a large migration, the rule still applies to the code you touch — but with a caveat: **don't polish code you're about to delete.** Cleanup in a module scheduled for strangulation in six weeks is wasted effort, and worse, it invests people in keeping it. Direct opportunistic cleanup at the code that will survive. ## How to answer Open with the local-vs-structural test, list the *spectrum* (not a binary) with Strangler Fig and branch-by-abstraction in the middle, give the concrete failure mechanisms of big-bang rewrites, name the honest cases where a rewrite wins, and finish with how you'd gather evidence (hotspots, defect density, lead time) rather than deciding on taste.