Safe Incremental Coding — the Legacy Net

Take untested code to a state where you can change it safely, distilled from Dave Farley's The Software Developers' Guidebook. The single measure of "good" throughout is ease of change: quality in code is your ability to change it safely — and for legacy code, that ability starts with a characterization test net built before any change.

Work incrementally on the area you actually need to touch, never as a big-bang rewrite. Stabilise the code you're about to change, change it, move on.

Two principles frame every step:

• Quality is your ability to change the code. Every step exists to make the code easier to change.
• Refactoring is always behavior-preserving. If a change alters what the code does, it isn't refactoring — it's a behavior change needing its own test and its own step. Run the net (step 1) after every transformation to confirm behavior is unchanged.

Why this is a separate skill from tdd

Do not retrofit fine-grained, TDD-style unit tests to legacy code. The code isn't shaped for them yet; writing them now bakes in the bad structure. Approval/acceptance tests at a coarser boundary are the right net for now. This rule deliberately opposes tdd's Iron Law (no production code without a failing test first) — which is exactly why the two stay separate skills: tdd assumes code shaped for tests; legacy code must first be reshaped under a coarser net.

The five steps

Ordered — you can't safely simplify code until there's a net under it, and you can't see the structure until the clutter is gone.