Yes, but the comment I replied to implied that software will just stop working. If software has been working for years and then stops working, it's usually something fairly small than can be hacked quickly.

In my specific case, the tool had a whole bunch of hardcoded values. It checked authorization against an LDAP server, that all changed. Connected to a sql sever that moved + credentials changed. Assumed certain files existed on certain network drives which were moved.

Technically, it could have been solved by faking all the infrastructure. It also could have been solved by digging out the source code from tape drives. But everyone was running around saying it was "impossible". I was shocked how quickly people tossed out "impossible".

It could have been done with a simple hex editor, but the new values were longer than the old values, so the strings didn't fit. I put the new strings at the end of the .data section and then just changed a bunch of offsets.

I agree that if you're writing the next version of the software, you can't do that quickly when nobody knows how the current version works. But chances are, you're not writing the next version of the software quickly even without churn.

it's not really about how the software works. the source code says what it's doing. the thing is the source code is the product of a theory; a theory determines how you respond to the world. if that theory is lost, then updating--in the long-term sense--becomes hard, because the theory that you form might (probably) be incompatible with the theory that made the software. this incompatibility might make producing functioning software difficult, but more likely, the mismatch will make choices that don't make sense to, say, users, appear to be the obvious thing to do.