Too Old to Fail

I’ve been watching the Battlestar Galactica series recently. It’s a gritty sci-fi show about the remnants of a human civilization, looking for a mysterious planet (conveniently called Earth) after their home world had been destroyed by rebellious cyborgs. The title comes from the human’s only remaining battleship – Galactica – which only survived because it was being decommissioned and away from the action, and it was so old that the onboard systems were immune to a virus that erased everything else.
It made me think about, well, old things. Our society and culture place enormous value on youth and the new, from people to objects to ideas to software. Deleting old code is a joy.
But for some reason, code is deceptively hard to exterminate. Deleting files and classes and modules requires at least some understanding of their purpose, and if there’s one thing software developers dislike, it’s reading and understanding someone else’s code{{1}}.
There are also some benefits to keeping old or deprecated code around:

• Good design never goes out of style. Even as an example, an old but well-crafted piece of code is a learning opportunity.
• Code, over time, captures nuance and details that its replacement may miss. Suppressing the instinct to shun complicated and messy code, all the if statements and special cases are indicative of the complexity of the underlying problem. It’s very possible that the new hotness is not 100% functionally equivalent to its deprecated counterpart.
• Old systems serve as great backup mechanisms for their replacements.

Of course, this is all assuming that the code targeted for deletion is still well-written, that its fault mainly lies in changing requirements rather than just sloppy engineering. Rewriting for the sake of rewriting is one of those pitfalls teams unwittingly fall into and some argue it’s always a mistake for startups.
Sometimes all it takes is a Galactica to get you there.
[[1]]Or even just reading their own code, written six months prior.[[1]]