The Software That Predates Your Mortgage

Somewhere in a server room you'll never visit, a program written before mobile phones existed is processing your direct debit. It was written in COBOL – a language designed in 1959, partly by a woman named Grace Hopper, and still running an estimated 95 billion transactions a day across the world's banking systems. Not because anyone planned it that way. Because it worked.

Legacy Code Doesn’t Rot, It Accretes

That's the thing about legacy code that nobody tells you: it doesn't accumulate through laziness or incompetence. It accumulates through success. A system gets built, does its job brilliantly, and so everyone leaves it alone and builds the next thing around it. Then someone builds around that. Then someone else builds around that. Twenty years later, the original program is so deeply embedded in everything that touching it feels like pulling a brick from the bottom of a wall – and nobody is quite sure which brick is load-bearing.

The programmers who wrote it have retired, or moved on, or died. The documentation was always a bit patchy and is now largely useless. The language itself – COBOL, FORTRAN, even early versions of C – is barely taught anymore. Which means the people who genuinely understand these systems are in their sixties and seventies, and very much in demand. The NHS's patient record infrastructure runs on systems that predate email. Some local councils are still using software originally installed in the nineties, held together by patches that were themselves patched a decade ago by someone who's now a project manager in Swindon.

The Patches Are the Interesting Part

The patches are the interesting part, actually. Every time a new requirement arrives – a regulatory change, a new data field, an update forced by the year 2000 bug that cost businesses an estimated £400 billion to fix worldwide – someone adds a layer. Not by rewriting the foundation (too risky, too expensive, too unknown), but by building carefully around it. Like a medieval cathedral where every century adds a new wing without anyone being entirely sure what the original architect was thinking.

For a deeper dive into why businesses rarely spot the rot until something fails, *The Quiet Rot You Don't Notice Until the Ceiling Falls In* is worth a read.

Works Until It Suddenly Doesn’t

The result is systems that work, mostly, until they suddenly and catastrophically don't. The TSB migration disaster in 2018 locked 1.9 million customers out of their accounts for weeks, partly because untangling decades of accumulated code turned out to be far harder than anyone projected. The system hadn't failed while left alone. It failed the moment someone tried to modernise it.

Which is the quiet paradox at the heart of all this: the software that causes the most trouble is rarely the buggy, badly-written stuff. It's the stuff that worked so well for so long that nobody dared look inside. The traffic lights outside your window may well be running firmware from the early 2000s. Your GP's records system almost certainly has code in it that's older than your GP is. It keeps working right up until the moment it doesn't, and by then, the person who knew how to fix it is enjoying their retirement in Dorset and very much not answering emails.