(He was a good contractor, so clearly having the latest billing software is not the deciding factor in that.)

The big problem will almost always be some hardware dependency that breaks, almost always in I/O. I've seen video software used by TV producers that depended on an ISA (not EISA nor PCI, ISA) card to read NTSC input and impose text over it. And it broke as they were getting ready to add commentary to a live broadcast of a race (which I was driving in.)

The world is full of machine tools and metrology devices that are stuck on some ancient computer/software because they made a weird proprietary protocol over the top of a centronics connector, or some other "WHAT were they thinking??" construction...

All of these could be overcome with a new I/O device, and/or writing a device driver. So using say a raspberry PI that talks ethernet to your "monitor" PC is probably relatively change proof.

If there is any documentation, if anybody can find said docs, if there's budget for a new I/O card and the device driver to go with it. Often the parties who have those resources would rather sell you a new machine tool, metrology machine, or I suppose, nuclear reactor (:-)

Of course, certification is a big deal... A particular certification structure led to the 737 MAX tragedies. And since certifying authorities don't always have detailed tech knowledge of what things are, they have a hard time saying "no, you can't slide that by, you have to build and certify a new thing".

This was all code in the heart of an OS - thread switching, interrupt dispatch, synchronization mechanisms - things where even the most rare and exotic error might actually occur and cause a disaster.

But some hazard/cost computation is needed. There was an article in the '90s about a team doing software for an arm for space work (maybe on the shuttle) - they were hyper careful. I figured out that if all of windows had been made at that rate out of code output it would take 100 years to finish and would cost several trillion dollars. Not long after that that space arm suffered some kind of software failure, in space. Wasn't for want of effort by the dev team.

Remember that many errors arise from things outside the code you wrote/studied - some other code corrupted something, buggy behavoir in hardware, and so forth.

As for coding by hand, simulating by hand, flow graphing by hand, I don't think those were all that unusual, just one person took it to extremes and wrote about it.