I did a consulting gig at Allstate around the time of Y2K. I chatted with a senior architect who had been with the company for over 20 years. He noted that there were such a vast array of programs and systems in place, some of which had been running for at least 40 years. I wonder if any of that code had been read, good or bad, for decades. And I am willing to bet that the source code for some of it was lost.

This of course led to no small level of anxiety during the run up to Y2K.

As a side note, while I was there, the dictum came down that there was to be no more assembler programming to be done.

I know what you are thinking. They should just burn the mainframe with fire and rewrite it all. I recommend the book https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/....

I think you are talking about technical debt. Read the classics: The Phoenix Project, DevOps Handbook and Google SRE Book for plenty of discussion. Another great book on legacy software: https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/...

The author also has a long history of working at many places that aren't defense contractors, and a great book on working with large legacy systems (read: Cobol, mainframes, et al but relevant to all developers) https://www.amazon.ca/Kill-Fire-Manage-Computer-Systems/dp/1...