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 code1.
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
ifstatements 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.
Or even just reading their own code, written six months prior.↩
I agree with your three points. However, I’d have to say that deleting old code should be safe as long as you your software is thoroughly tested. After deleting files you feel aren’t necessary your tests should be able to tell you if it was in fact necessary. Too many times I’ve deleted code I thought was un-necessary, which caused bugs, due to lack of tests and documentation.
Agreed. The other time when it’s good to delete code is when the requirements have undisputedly changed; the tests can disappear along with the code itself. Both things are not easy to do, and if anything it takes discipline to take time out of product dev. to maintain these codebases.