Have to disagree with this. Unmaintained code is a massive security risk. Eventually someone will find a flaw in some part of your stack and your code is dead.
No, your code still isn't dead. It's revealed to be potentially exploitable by someone, somewhen, maybe. Code is not accruing danger or becoming dead by just sitting there, untouched.
Unless you've been particularly careful with your build chain, your ability to actually do anything with an untouched codebase degrades over time. There may well come a point where just getting the damn thing to build so you can release a version with whatever vulnerability patched can cost more than the remaining lifetime value of leaving it running. In that case, it's already dead, it just doesn't know it yet.
What you say "being particularly careful with your build chain" was the status quo just few years ago, and I'd argue is still good engineering. You should pin your dependencies, and updates of everything - including build tools - should be explicit steps in the process.
This should be trivial on the small (just pin versions and disable automatic updates of your build tools / package repos), and with recent proliferation of cheap VMs and containers, it should be simple over time - you should be able to pull a 5 years old image full of old software and rebuild the original binary.
> There may well come a point where just getting the damn thing to build so you can release a version with whatever vulnerability patched can cost more than the remaining lifetime value of leaving it running. In that case, it's already dead, it just doesn't know it yet.
Vulnerabilities aren't sins, they are things that can be fine to leave unfixed. The software isn't dead, it'll just keep running with a known exploitable issue.
> You should pin your dependencies, and updates of everything - including build tools - should be explicit steps in the process.
Yes, and in the not uncommon case where part of the build environment is left unspecified, the untouched code accrues debt over time. As you say, it's possible not to take on that debt by making a significant investment up front. This isn't an argument against the debt metaphor, it's an argument for it.
> Vulnerabilities aren't sins, they are things that can be fine to leave unfixed.
My point doesn't change if you s/vulnerability/sufficiently serious vulnerability/.
It does, though. A single line might not change - but the world around it is always shifting. Libraries in frameworks, Operating Systems, drivers, external data structures - nothing stays static in the environment our code lives in. As long as code is running, it needs to be maintained. (Most of the time it can be negligible, sometimes serious...)
Most of the things you mentioned are a choice, not something inherent to the code as an artifact. If the external systems your code interfaces with change, you need to change your code. Other than that, updating your OS, libraries, drivers - these are all choices. You can not update them, and the code should run exactly as fine as it did when originally written. You can virtualize the environment to mitigate the risk of the underlying hardware platform going down or you. Code decay, to me, is mostly self-inflicted.
