Fearless refactoring

The technical half of refactoring is solved — small steps, tests, mechanical tooling. What actually stops refactoring is social: the merge-conflict tax on other people’s in-flight work, and blame asymmetry — the improver pays for the disruption while the benefit is diffuse. The captured redesign-fear pair is the cleanest statement of both:

• The spiral (Agile Otter, clippings/agileotter-blogspot-com-2026-09-why-redesign-doesnt-happen-enough-html.md): a righteous, well-tested refactor touches 15 files → N−1 colleagues have in-flight changes → conflicts, slowdowns, defects land on you → the rational move is to abandon good changes → “the code remains anchored to some point in the past… actual functions are written as EXCEPTIONS to the flow it no longer follows.” The fear is a social effect, not a technical one.
• The defusing (ploeh, clippings/blog-ploeh-dk-2026-10-02-redesign-without-fear.md): Strangler Fig at the code level. Stage 1: build the new design side-by-side, inert — new files only → no merge conflicts — but push and share it so it’s visible. Validate secretly: do real migrations on a private branch, get evidence the design is right, then share the design without the strangling commits. Stage 2: migrate call sites one at a time, granularity of your choosing. The insight: decouple the risk of designing from the risk of migrating.

Supporting mechanics already in the vault:

• Git worktrees — the private validation branch without touching your checkout
• rerere + auto-bisect (Git Legit captures) — shrink the conflict tax and localize regressions
• mergiraf (in Diff tools) — structural merge that makes the 15-file righteous change survive text-level conflicts
• Approval/characterization tests (in Working with legacy code) — the evidence that lets you push with a straight face
• Operating principles — “engineer systems with safety controls so everyone can ship safely” is the org-level version of this note

The general law both posts point at: make good changes cheap and blame-free, or they won’t happen — process design (small PRs, trunk-based, strangler patterns) beats exhortation (“we should refactor more”).

Related: Working with legacy code (the technical half) · xkcd (the refactoring-comic canon) · Performance engineering (measure first)

• Codemod — the mechanical-tooling family named: AST/LST codemods (OpenRewrite, jscodeshift, ast-grep) as the deterministic half of solved technical refactoring.