The Programming Language Nobody Talks About Is Quietly Running the Global Economy.
And It’s Older Than Your Parents.
Right now, while you read this, your bank balance is being calculated by code written before the moon landing. Not metaphorically. Literally. The language that moves $3 trillion every single day was invented in 1959 - and almost nobody alive fully understands it anymore.
Last semester I was in a systems programming lecture when the professor mentioned, almost as a throwaway line, that the New Jersey unemployment system collapsed in 2021 because they couldn’t find enough people who understood the programming language it was built in. Tens of thousands of people couldn’t access their unemployment benefits during a pandemic. The system had worked flawlessly for decades. The crisis wasn’t technical. It was human. They had simply run out of people who could read the code.
I wrote down the name of the language. I went home and looked it up. And then I spent the next four hours down a rabbit hole that quietly changed how I think about software, systems, and the thing we call “progress” in engineering.
The language was COBOL. Common Business-Oriented Language. Written in 1959. And it is, right now, today, as you read this - running more of the world’s critical financial infrastructure than Python, Java, and JavaScript combined.
I’m a third-year CSE student. I’d never written a line of it. I’d never been taught it. I’d never even seen it mentioned in a curriculum. And yet the code running inside my bank, processing my transactions, calculating my balance - it’s COBOL. Almost certainly.
Let me give you a quick technical picture, because COBOL gets dismissed as “old” without anyone explaining why it still exists at all.
COBOL was designed specifically for business data processing - reading massive files of records, performing calculations on them, and writing the results back out. It was built to handle what engineers today call batch processing at enormous scale: end-of-day bank settlements, payroll calculations, insurance claims processing, tax filings.
Notice how readable that is - almost like English. That was intentional. Grace Hopper, the US Navy admiral and computer scientist who led the team that created COBOL, believed that business people needed to be able to read and verify their own programs. She wanted code that managers could audit. In 1959, that was a radical idea.
But here’s the engineering reality that keeps COBOL alive in 2026: for high-volume sequential batch processing of structured financial records, nothing written since has meaningfully beaten it. Not in throughput. Not in reliability. Not in the cost of running it on mainframe hardware specifically designed for it. The IBM Z-series mainframes running COBOL today process transactions at speeds and reliability levels that would require enormous distributed Python or Java infrastructure to match - and that infrastructure would cost more, fail more often, and take longer to audit.
It’s not that nobody tried to replace it. They did. In the 1990s, banks spent billions attempting to migrate off COBOL into modern systems. Most of those projects failed. Some spectacularly. The systems were simply too large, too interconnected, and too correct to risk rewriting.
Here is the part that should concern every engineering student reading this - and I mean genuinely concern, not in a clickbait way.
The average age of a working COBOL programmer today is somewhere between 55 and 60. The community is not being replenished. Almost no university teaches it. Almost no bootcamp covers it. When a third-year CS student asks their professor about COBOL, the typical response - I know because I tried this - is a mild laugh and a pivot back to the syllabus.
The 2021 New Jersey collapse was a preview. When COVID hit and millions filed for unemployment simultaneously, the system - a COBOL application running on a mainframe - was overwhelmed not because it was slow, but because the team maintaining it was too small to adapt it quickly. The Governor of New Jersey went on television asking for COBOL volunteers. In 2021. During a pandemic. Because the state couldn’t find engineers fast enough.
New Jersey is not alone. The US Social Security Administration runs COBOL. The IRS runs COBOL. Every major bank in India, the US, Europe and Australia runs COBOL at its core. The entire SWIFT international banking messaging network - the system that moves money between countries - has COBOL components. The global financial system is held together, at its foundation, by code that most of the engineering world considers a museum exhibit.
Every few years, a major bank announces a “COBOL migration project.” These announcements are met with nods of approval from shareholders and analysts who imagine a clean handoff from old code to new. What actually happens is more interesting - and more instructive for engineering students.
The problem is not the COBOL itself. The problem is the business logic embedded inside it - accumulated over sixty years of edge cases, regulatory changes, market adaptations, and fixes applied by engineers who are now retired or dead. Nobody wrote down why half of those decisions were made. The code is the documentation. And the code is in COBOL.
Commonwealth Bank of Australia spent five years and $750 million migrating off their core COBOL system. TSB Bank in the UK attempted a migration in 2018 - it went catastrophically wrong, locking 1.9 million customers out of their accounts for weeks, costing the bank over $300 million in fines and compensation. The CEO resigned. The migration team disbanded. TSB still runs COBOL.
From a pure systems engineering perspective, this is a fascinating and terrifying problem. The COBOL systems are correct - they produce the right outputs, reliably, at scale. The humans who understand them are disappearing. The business logic they encode cannot be perfectly reconstructed from the outside. And the risk of a failed migration is existential for any institution that attempts it.
It is, in engineering terms, a knowledge transfer problem that was never solved — and the window to solve it is closing faster than anyone in a CS classroom is being told.
I want to be precise about the takeaway here, because there are two wrong ways to read this story.
The first wrong read: “I should learn COBOL.” Maybe. IBM offers free COBOL training through their Open Mainframe Project. If you genuinely want to be one of the rarest and most employable engineers on the planet, that path exists and pays extraordinarily well. Banks are paying $200-400 an hour for COBOL contractors right now. That is not a typo.
The second wrong read: “Old technology always gets replaced eventually, so this doesn’t matter.” This fundamentally misunderstands what the COBOL story is actually about.
What COBOL teaches us - and what I think every engineering student needs to sit with - is that systems accumulate knowledge that their creators never intended to store. The logic of decades of human decisions gets encoded into code that nobody thought to document, because the people writing it assumed they’d always be around to explain it. They weren’t.
Every system you build in your career will do this. Every shortcut you take, every assumption you hardcode, every edge case you handle with a comment that says “// fix this later” - that is future debt being signed by a version of you who won’t be there to cash it in. The COBOL crisis is not a story about an old language. It is a story about what happens to engineering knowledge when it isn’t transferred.
After that lecture and the rabbit hole it opened, I made two changes to how I think about engineering.
The first is practical: I started actually documenting my decisions, not just my code. Not what the code does - any decent engineer can read what code does. Why I made the decision I made. What I considered and rejected. What the edge cases are that I know about. What I’d change if I had more time. Future me - or future anyone - deserves that context.
The second is harder: I started taking the unglamorous, unsexy parts of software engineering more seriously. The stuff that doesn’t make a good GitHub profile - reading legacy systems, understanding why old decisions were made, sitting with complexity instead of immediately reaching for a rewrite. That skill - the ability to reason about systems you didn’t build, in conditions you didn’t create - is one of the most valuable things an engineer can have. And it’s almost never taught.
COBOL didn’t survive sixty-seven years because it’s beautiful. It survived because it was correct, and reliable, and the cost of replacing it kept being higher than the cost of keeping it. That’s a lesson about engineering that no language or framework can teach you. Only the history of systems that outlived their creators can.
Open your banking app right now. Look at your balance. That number was just computed by a program older than your parents, running on hardware that looks like something from a Stanley Kubrick film, maintained by a shrinking team of engineers most of your professors have never met.
And somewhere in that code, written by someone who retired before you were born, is a comment that says // TODO: clean this up later.
Later never came.
// END OF FILE
If this made you curious: IBM’s Open Mainframe Project offers free COBOL learning resources at openmainframeproject.org. The Grace Hopper biography “Broad Band” by Claire L. Evans is the best non-technical entry point into this history.
The Programming Language Nobody Talks About Is Quietly Running the Global Economy. was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.
