Some code is immortal, and not for good reasons.
There’s a stored procedure in our production database that was written in 2008 by an engineer who left the company in 2010. It processes payroll adjustments. Nobody fully understands it. Every year, someone proposes rewriting it, and every year, the proposal is deferred because the risk of getting it wrong is higher than the cost of leaving it alone. It has outlived three CTOs, two database migrations, and one acquisition.
I used to think immortal code was a sign of failure — that we’d failed to document, failed to refactor, failed to do our jobs. Now I think it’s a sign of something more interesting: the code is correct enough, and the cost of replacing it is high enough, that the rational choice is to build a fence around it and let it run.
Not all code deserves to be rewritten. Some code has earned its retirement — not by being good, but by being reliable. The subroutine has never caused an incident. It has never returned a wrong result. It is ugly, undocumented, and absolutely trustworthy. I will probably outlast it, but I am not sure.