Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

Stimulus and response have to be as close together as possible in order for us to change our habits. When developers don’t see the consequences of our actions until months later, it doesn’t properly register. It’s as if we’re living by the motto: It’s not my job to find the errors; it’s my job to create them.

A legacy is the part of the dead that remains influential.

And it’s not just that batching is inefficient—and we’re going to talk about the inefficiencies as we start to look at the cadence of different release cycles—it forces us to build things that are unchangeable. This is far more subtle, but vitally important.

Software development has many contraindications where the “right” approach in one situation is the wrong approach in another situation.

Michael Feathers asks what we think about when we hear the term “legacy code”: If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don’t really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyo

I was the third consultant they hired, and the first not to address it as a “people issue.” What I saw was a legacy code issue. Their software was brittle and hard to work with.

When I’m looking at a system that was built years ago with no documentation and poorly named variables, I sometimes feel how an archaeologist must feel pondering the mysteries of a lost and ancient civilization from a shard of pottery. It’s just so little to go on.

And the bottom line was: People began to care again.

Different people have different definitions for “legacy code,” but put most simply, legacy code is code that, for a few different reasons, is particularly difficult to fix, enhance, and work with.