Originally published November 2019, updated May 2026

Legacy Code: It’s Not Just Old Code

The term “legacy code” gets thrown around constantly in software circles, yet somehow everyone means something slightly different by it. To a lot of developers, it just means old. Code that’s been sitting around a while, written by someone who might not even be at the company anymore. And that’s not entirely wrong — but it’s not entirely right either.

The word “legacy” is the tell. We don’t use it to mean “old” in any other context. A legacy is a bequest. Something someone left you when they moved on. That framing matters, because it changes how you think about what you’ve inherited. And specifically, it helps you think clearly about the legacy code that causes real trouble, which is not all legacy code, but is enough to deserve proper handling.

See my original video on this topic on YouTube: 

What Was Left To You

Think about what an inheritance can look like. On one end of the spectrum, you get a pile of cash — liquid, flexible, useful for almost anything. That’s the legacy code equivalent of a well-structured, well-documented module that quietly does its job and asks for nothing in return. On the other end? Maybe you got a 75-year-old cockatoo with a bad wing. That bird is going to outlive you, require constant attention, and cost you more in vet bills than you’d care to admit. Some legacy code is exactly that.

Most of the time, though, legacy code is closer to inheriting a house. And houses come in flavors. There’s the house that just needs a coat of paint and some new carpet — you move in, make a few improvements, call it done. There’s the fixer-upper: real work ahead, but there’s something worth saving underneath. And then there’s the money pit. You pull off one piece of drywall and find mold. Fix the mold and find leaking pipes. Fix the pipes and blow the pressure elsewhere in the system. The more you dig, the worse it gets.

Every working software organization has at least one money pit. Usually it’s the piece of code nobody wants to touch, the one that “just works” as long as you don’t look at it too hard. The original author is long gone. Nobody fully understands it. Everything depends on it. And when you do touch it, you’re the plumber who fixes one fitting and blows the pressure in three different places.

The Real Question

When you’re staring at legacy code that’s giving you trouble, the right question isn’t “how do I fix this?” The right question is “should I fix this?”

Is this a historic mansion worth restoring? Or a condemned building dressed up in new paint? If you’re spending more time patching than building, if every fix creates two new problems, if nobody on your team can confidently describe what this thing actually does — that’s not a maintenance problem. That’s a demolition decision you’re putting off.

To be clear: a lot of legacy code is fine. Some of it is the most valuable thing in the codebase — battle-hardened, edge-case-aware, quietly keeping the lights on. The inheritance framing applies there too. A pile of cash is still a legacy. You just don’t agonize over it.

The point is that calling something “legacy” shouldn’t be shorthand for either “untouchable” or “doomed.” It should be the start of an honest assessment. Know what you’ve inherited. Know what it’s worth. Then decide.