I have to disagree. These systems aren't "survivors" - they're held together with a fragile weave of scripts, hacks, unsupported hardware and outdated knowledge. Often treated as a black box, they become an object that people have to hand-nurse through issues that would never trouble modern systems. The amount of effort and money that's expended to maintain these systems is typically far more than the upfront cost would be to replace them every decade with a more modern one, but that would look bad in the short term financials, so we keep babysitting the tower of glass and praying it doesn't fall.

I spent multiple years of my life working on a (at the time I started) decade+ project to retire such a system (i.e. a duct-taped hodgepodge of poorly documented COBOL and mainframe assembler that was understood and maintained by staff who was entering retirement age at an astounding rate), at a "midsize" financial company (i.e. between 3k and 4k employees, all told). While the cost of maintaining the old system was certainly high, it worked astonishingly well (provided you didn't need to add new features, such as a "graphical interface"), and the cost and difficulty in replacing it was truly enormous. I think you're drastically underselling the difficulty of re-implementing a company's entire suite of LOB software, complete with migrations and training, and likely with very little in the way of flexibility to change the core business rules/logic.

Furthermore,

> they're held together with a fragile weave of scripts, hacks, unsupported hardware and outdated knowledge

Swapping out COBOL for typescript and mainframes for linux boxes and a pile of YAML is not going to change any of that. People can and will build garbage with any set of tools you give them. Not ever software problem is like use-after-free where you can fix it forever with a sufficiently clever piece of tech.

> These systems aren't "survivors" - they're held together with a fragile weave of scripts, hacks, unsupported hardware and outdated knowledge.

It can be, depending on the system and who's complaining about it. Sometimes a fragile, buggy, mess of a legacy system is actually fragile and buggy, with failures causing downtime or lost business, and creaky processes slowing new development to a crawl. Sometimes it's just a system that has an unfamiliar or slightly less ergonomic developer experience, that uses older technologies that some developers don't want to learn. You have to look past the complaints and judge for yourself.

And yet the flip side where companies set piles of cash on fire trying to replace that legacy stuff is also common.

e.g. https://www.computerweekly.com/news/252446965/Lidl-dumps-500...

A reply to myself since I can't edit: Survivorship bias may not completely describe what I'm talking about here but another commenter posted about Lindy Effect, which is 100% on the nose:

https://en.wikipedia.org/wiki/Lindy_effect

These systems are in place and will continue to be maintained simply because they've stood the test of time.