Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software
David Scott Bernsteinamazon.com
Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software
There’s a difference between a recipe and a formula. You can make, say, marinara sauce from a recipe and it will taste the same as the marinara sauce made by someone else from the same recipe, but only if both cooks follow that recipe in exacting detail. But if one cook adds a little more pepper, and someone else uses more basil and less oregano, i
... See moreMichael 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
... See moreThey knew they had to address both their existing legacy code as well as all those bad habits they’d accumulated along the way that got them into this situation.
Their core developers were brilliant, but they also had a second level of junior developers and offsite or second-site teams that were allowed to slip into an attitude of “code monkey-ness”—micro-focused on building “just this feature,” not thinking about how that single feature would integrate into the whole and unaware that some of the things the
... See moreStimulus 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.
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.
As a young industry we’re still figuring things out and learning to distinguish what’s important from what’s unimportant.
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.
And the bottom line was: People began to care again.