by Gary Worthington, More Than Monkeys

When Michael Feathers published Working Effectively with Legacy Code in 2004, he wasn’t writing about nostalgia. He was describing a kind of professional dread that every engineer still knows today — the moment you open a file, stare at a wall of untested logic, and feel your confidence drain away.

Two decades later, our tooling is better, our languages are cleaner, and our build systems are faster. But that feeling hasn’t gone anywhere. The book’s lessons are as relevant as ever, because they’re not about syntax or frameworks — they’re about the psychology of change and the discipline of regaining control.

Legacy Means “Code Without Safety”

Feathers gave us a definition that still hits home:

“Legacy code is code without tests.”

He wasn’t being clever; he was being precise. Legacy isn’t about age or technology; It’s about the absence of safety.

Without automated tests, every change is a risk. You can’t know what will break, so you stop making changes at all. Over time, progress slows, fear grows, and what was once a product becomes a liability.

That truth is even sharper today. Modern teams move faster and ship more often, but they also accumulate debt faster. A six-month-old codebase with no tests can feel older than a ten-year-old one that’s well-covered. Legacy is about confidence, not chronology.

Control Comes Before Improvement

One of Feathers’ key ideas is the notion of seams — the places in code where you can alter behaviour without touching everything else.

In practice, that means identifying where you can introduce boundaries: extracting functions, passing in dependencies, or wrapping external calls. Once you can control those points, you can start to reason about the system and, eventually, refactor it safely.

That principle hasn’t changed. Every effort to make messy code maintainable still begins by finding control points. It’s the difference between working blind and working deliberately.

Modern tooling makes it easier — dependency injection, mocking libraries, and clear module systems all create seams for us — but the underlying discipline is the same. Before you improve anything, you must first make it controllable.

Learning Before Fixing

Feathers also introduced characterisation tests — tests that record what the code currently does, even if you don’t yet know whether it’s correct.

The idea is simple but powerful: don’t start changing behaviour until you understand it. Capture what happens today, protect it with a test, and then refactor underneath that safety net.

It’s a mindset shift that still matters. Too many teams jump straight to rewriting logic they don’t understand, only to discover later that the original behaviour, however odd, existed for a reason. Characterisation tests protect against that. They let you make progress without breaking what already works.

Legacy Is Accelerating

Software becomes legacy faster than ever.

In the early 2000s, a system might have lived for years before being labelled “legacy.” Today, something built last summer can already feel untouchable if the original developers have left and the tests are missing.

The speed of modern delivery amplifies the issue. Frameworks evolve, dependencies change, and cloud services deprecate overnight. Each of those shifts leaves behind a trail of code that no one wants to maintain.

Feathers’ message — that safety comes from understanding, not from rewriting — is even more urgent in that context. You can’t outrun legacy. You can only learn to manage it.

The Fear–Control–Confidence Cycle

The book’s deeper insight isn’t technical at all; it’s psychological. It describes how teams move from fear to confidence.

1. Fear: The code feels fragile. Every change might break something.
2. Control: You introduce seams and tests to observe and predict behaviour.
3. Confidence: With safety in place, you can improve the design.

That’s still the pattern every good team follows. The technologies have changed, but the emotions haven’t. You don’t overcome legacy by bravado or rewrite — you overcome it by creating small islands of safety until the fear recedes.

Why Rewrites Rarely Work

Feathers warned against the temptation to start over. It’s advice that’s still ignored, and still right.

When you rewrite a system, you also throw away its accumulated knowledge: the odd conditions, the awkward edge cases, the pragmatic shortcuts that reflect reality rather than theory. The result is often a “new” codebase that behaves differently in subtle, painful ways — and still has no tests.

The incremental path he described is slower at first but faster in the long run. You change a little, test a little, and keep shipping. The result is software that evolves instead of collapsing under the weight of its own complexity.

Working Effectively in 2025

Feathers’ original audience was C++ and Java developers. But his ideas extend to everything we build today: application code, infrastructure, pipelines, and data flows.

Anywhere we make changes without safety nets, we repeat the same mistakes. A Terraform stack with no validation tests is legacy. A deployment pipeline that no one understands is legacy. A service no one dares touch because “it just works” is legacy.

The context is different, but the remedy is identical: build confidence through understanding and controlled change.

The Same Problems, Better Tools

The book’s core techniques all have modern equivalents.

Where Feathers taught us to introduce seams — creating boundaries in the code where behaviour can be swapped or intercepted — we now think in terms of dependency injection and clear module boundaries. The goal is the same: make the system predictable enough to change safely.

His idea of characterisation tests shows up today as snapshot, regression, or contract tests. They record what a system does right now, giving you a way to refactor without losing its behaviour.

What he described as test harnesses has evolved into the automated pipelines and validation steps that guard modern releases. We rely on continuous integration to provide that feedback, but the intent is identical: detect regressions early and often.

And where he spoke of refactoring toward patterns, we now refactor toward simplicity — fewer moving parts, clearer boundaries, and code that tells the truth about what it does. The shape of the tools has changed, but the principles are exactly the same: gain control, add safety, then improve.

Why the Book Still Matters

Working Effectively with Legacy Code survives because it deals with human limits, not just software limits. It accepts that code rots, that people move on, and that systems outgrow their structure. But it also gives us a toolkit for reversing that decline.

Every technique — from extracting seams to writing characterisation tests — is a step towards clarity. And clarity is what every engineer actually wants.

You don’t need to worship the book. You just need to absorb its posture: calm, methodical, and unafraid of mess. That’s what effective work looks like, regardless of year or language.

Final Thoughts

Feathers’ book endures because it speaks to something permanent about software development. Systems grow messy. Deadlines squeeze quality. People come and go. None of that is new, and none of it will stop.

What matters is how we respond. The answer hasn’t changed since 2004: make the system safe to change, one test at a time.

If you understand that, you don’t need to fear legacy. You just need to start working effectively with it.

Gary Worthington is a software engineer, delivery consultant, and fractional CTO who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance.