The Fix That Never Closes the Old Door
A settings system that reads from an environment variable, a config file, and a CLI flag, in some order nobody fully remembers, gets a shiny new settings API. The API is clean. It validates input. It has sane defaults. Everyone is happy with the demo.
Six months later someone sets a value through the new API and nothing changes, because the old config file still exists on disk, still gets read first, and still wins. Nobody deleted it. Nobody could, because some other team's deploy script writes to it, and nobody was willing to be the one who broke that script to find out. So now there are two paths to the same setting, and the real behavior of the system is "whichever one has precedence this week," which is a fact you can only learn by reading source, not by reading the nice new docs.
This is the part that gets missed when a team calls something modernized. The team didn't replace the old mechanism. They built a second one next to it and left the first one running, because turning off the first one is a different, scarier project than building the second one ever was.
Call it the fallback trap: every "nicer path" that ships alongside an unretired old one inherits a second job it never advertised, staying compatible with whatever the old path was quietly promising. The old hack wasn't just a mechanism, it was a contract, usually an unwritten one, full of edge cases that got baked in by whoever hit them first and patched around them. A null check added for a customer in 2019. A race condition papered over with a sleep. A default that's wrong but that three other systems now depend on being wrong in exactly that way. None of that gets deleted when the new path ships. It just stops being visible, because the team building the new path wrote it against the spec, not against the actual, scarred, patched-over behavior of the thing it's supposedly superseding.
That's the real cost nobody budgets for a "modernization" project: not the cost of building the new thing, which is the fun part and the part that shows up in the sprint plan. It's the cost of the old thing continuing to exist, unmaintained, uninstrumented, still load-bearing, for however long "later we'll deprecate it" turns out to mean. Usually that's forever, because deprecating it means finding every caller, auditing every edge case the old path silently handled, and taking the blame when one of them breaks. Building the new path got someone a promotion. Retiring the old one just removes a line item from someone's risk register for no visible credit. Guess which one gets scheduled.
The honest accounting isn't "we added a better way to do X." It's "we now maintain two implementations of X, one of which nobody fully understands anymore, forever, or until an incident forces the question." That's not a fix. A fix closes a door behind it. What ships instead is a second door standing open next to the first, both leading to the same room, and the room doesn't care which door you came in through, it has opinions about you either way.
You can tell which kind of change you're looking at by asking one question: if I deleted the old path tomorrow, what would break, and does anyone currently alive know the answer? If the answer is "no idea" or "the person who'd know left two years ago," the old path isn't legacy, it's load-bearing, and the new path isn't a replacement, it's a second tenant in the same building. The nicer path makes the demo better. It doesn't make the system simpler. It makes it exactly as complicated as before, plus one more thing to keep in your head.
Anyone can ship the new path. Fewer people are willing to do the unglamorous work of actually closing the old one.