Working Effectively with Legacy Code

The problem it solves

Most programming books assume you are writing new code. Most jobs involve changing old code, often code nobody fully understands, with no tests to tell you whether you broke something. Feathers defines legacy code simply as code without tests, and the whole book is about getting from there to code you can change with confidence.

The core dilemma is circular: to change code safely you need tests, but to add tests you often need to change the code. The book is a toolkit for breaking that circle with small, careful edits.

Key ideas you will keep using

• The legacy code change algorithm: identify change points, find test points, break dependencies, write tests, then make your change and refactor.
• Seams: places where you can alter behaviour without editing code in that spot, such as passing in a dependency, overriding a method in a test subclass, or swapping something at link time. Finding seams is how you get a class into a test harness.
• Characterisation tests: tests that record what the code currently does, not what it should do, so you notice any change in behaviour.
• Sprout method and sprout class: write new behaviour in new, tested code and call it from the old code, rather than growing the untested mess.
• Wrap method and wrap class: add behaviour before or after existing code without editing its internals.
• Dependency-breaking techniques: a catalogue of around two dozen named moves, such as extracting an interface, parameterising a constructor or introducing a static setter, each with steps.

How the book is organised

The first part explains the mechanics of change and seams. The middle part is written as questions a developer actually asks, such as "I don't have much time and I have to change it", "I can't get this class into a test harness", "This class is too big and I don't want it to get any bigger" and "I need to change a monster method and I can't write tests for it". The last part is the catalogue of dependency-breaking techniques. That question-based middle makes it easy to open at the chapter matching your current problem.

Is it still relevant?

Published in 2004 with examples mainly in Java, C++ and C#, it can feel dated in its tooling: modern IDEs automate some of the refactorings, and mocking libraries make some techniques easier. The ideas have not aged. It averages 4.14 out of 5 from about 4,700 ratings on Goodreads (September 2026), and it remains the standard recommendation on this topic.

How to use it

1. Read the first part (the mechanics of change) once.
2. When you meet a hard piece of code at work, find the matching question chapter and apply it.
3. Start small: write one characterisation test around the function you need to change today.
4. Pair it with Refactoring, which assumes tests exist and shows how to improve the design once they do.

Common questions

Do I need to know testing first? Basic unit testing in your language helps; the book teaches the rest.

Is it useful for dynamic languages like Python or JavaScript? Yes. Some techniques are built for static languages, but seams, characterisation tests and sprouting apply everywhere.

Best for: developers joining or maintaining an existing codebase, especially one with few or no tests.