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

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

The whole development team didn’t understand the reasons behind the technical practices. They ended up cutting corners here or gaming the system there, creating little sub-teams—or even “teams of one”—operating with a different set of standards and an incomplete view of the whole system. This made integrating code a nightmare-like experience that n

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.

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.

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.

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

As a young industry we’re still figuring things out and learning to distinguish what’s important from what’s unimportant.

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