I agree with all of this, but even this is overlooking a simpler point: the software probably wasn't perfect in the first place. Even a few-line algorithm, isol

I agree with all of this, but even this is overlooking a simpler point: the software probably wasn't perfect in the first place. Even a few-line algorithm, isolated from any APIs or IO, can have subtle bugs. Remember the headlines when people noticed that most textbook implementations of binary search had an integer overflow bug? If you take any old C or C++ code, for example, it's extremely likely that it has at least one construct with Undefined Behavior. Many instances of that binary search issue had outright UB because of signed integer overflow, and most code has much more subtle UB than that. The more time passes the more likely that UB manifests with a newer compiler, a new OS version (especially if it's Library UB rather than Language UB), a new CPU family, etc. This is nobody's fault as such, UB wasn't well understood until compilers became aggressive enough to actually exploit the letter of the standard rather than the common intuitions. Even so, good luck finding old code that would pass modern scrunity. In the unlikely case that a program had absolutely no defects of its own at the time it was written, it could still use a deprecated API, make a stale assumption that increasingly limits its interoperability and versatility, fail to utilize modern resources like many-core CPUs and RAM larger than entire enterprise disk arrays used to be, etc. Any number of things could merit improvement without a single bug or change to requirements as such.