Why the World Still Runs on COBOL

1. A language older than the people who maintain it

Somewhere behind almost every card swipe, almost every pension payment and almost every tax return processed today, a piece of code written in nineteen fifty-nine is still doing the arithmetic.

The language is called COBOL, short for Common Business-Oriented Language. It is sixty-six years old this year.

Nobody planned for that. COBOL was built to solve one problem, for one decade. Instead it became the language that banks, insurers, airlines and governments still trust with the numbers that matter most, and nobody has found a way to fully retire it.

This video is about why a language most programmers have never touched still sits underneath so much of the world's money, and why replacing it keeps turning out to be harder than it sounds.

2. One meeting, one Pentagon, one language

The story starts on the eighth of April nineteen fifty-nine, when a computer scientist named Mary Hawes organised a meeting at the University of Pennsylvania. Businesses across America were buying computers, and every manufacturer's machine spoke its own private language. A program written for one computer could not run on another.

That meeting led to a bigger one. [CALLOUT] On the twenty-eighth and twenty-ninth of May nineteen fifty-nine, forty-one people met at the Pentagon, chaired by Charles Phillips of the United States Department of Defense. The Department had hundreds of computers on order, from different manufacturers, and no common language to program them in. A week later, on the fourth of June, the group that came out of that meeting formally organised itself as CODASYL, the Committee on Data Systems Languages.

Their goal was specific: a language for business, not for scientists or engineers, that read close enough to plain English for a manager to check it, and that would run on any manufacturer's machine without being rewritten.

3. Grace Hopper's head start

CODASYL did not start from nothing.

A US Navy rear admiral and computer scientist named Grace Hopper had already built a language called FLOW-MATIC, the first to let programmers write instructions in English words rather than mathematical notation. Hopper served as a technical adviser to the committee, and in nineteen eighty she said plainly that COBOL sixty was ninety-five per cent FLOW-MATIC. One of COBOL's own lead designers, Jean Sammet, was careful to say Hopper was not COBOL's inventor. What is not disputed is that without FLOW-MATIC to borrow from, the committee would have had far less to build on.

The first COBOL program ran on the seventeenth of August nineteen sixty, on an RCA 501. Four months later, on the sixth and seventh of December, the same program ran unchanged on both an RCA and a Remington-Rand UNIVAC computer. That was the entire point proven in one demonstration: one language, many machines.

4. Built for money, not for speed

COBOL was never designed to be fast, or clever, or small. It was designed to be read.

Its instructions look like sentences: ADD, SUBTRACT, MULTIPLY, MOVE, COMPUTE. A manager without a programming background could follow the logic of a COBOL payroll program line by line, which is exactly what the committee wanted for a language that would be handling other people's money.

It also did something quieter that turned out to matter enormously: it handled decimal numbers exactly. Currency has to add up to the penny, every time, and COBOL's packed-decimal arithmetic does that natively, without the small rounding errors that binary floating-point math can introduce. Fifty years later, that one design choice is still a reason banks are cautious about moving off it.

By the nineteen seventies, COBOL was the dominant language for business computing in the world.

5. The number that will not go away

In nineteen ninety-seven, the research firm Gartner made an estimate. About two hundred billion lines of COBOL code were in active use. They said that code ran roughly eighty per cent of the world's business transactions.

A different estimate is more widely repeated today. Reuters reported it in twenty fifteen, and the industry still cites it a decade later. It puts the figure at two hundred and twenty billion lines of active COBOL code. That code was said to run forty-three per cent of the world's banking systems. It was also said to run ninety-five per cent of the transactions passing through automated teller machines.

Both figures are estimates, not counts, because nobody has ever audited every mainframe on Earth. But the direction they point in has not changed: this is not a language quietly disappearing. It is a language quietly still carrying an enormous share of the world's financial plumbing.

6. Where it actually runs, in 2026

The applications are not exotic. Core banking systems that post deposits and withdrawals. Insurance policy administration. Airline reservation systems. Payroll and pension calculations for government employees. Tax processing.

The United States Internal Revenue Service is a case study on its own. Its main tax processing systems have run on COBOL for decades. In twenty twenty-four the agency announced a Digital First Initiative to move that processing from COBOL to Java, a project expected to take years, not months, precisely because of how much depends on the old code behaving exactly as it always has.

That is the pattern almost everywhere COBOL still runs: not a system nobody dares touch, but a system nobody can afford to get wrong while touching it.

7. The bug that proved how fragile it all was

For most of COBOL's life, programmers stored years as two digits to save expensive storage space: nineteen ninety-nine was simply "99". As the year two thousand approached, that shortcut became a problem. A computer reading "99" could not tell nineteen ninety-nine from some other year ending in ninety-nine. Left uncorrected, it threatened to treat the year two thousand as nineteen hundred.

Some studies attributed as much as twenty-four per cent of the total worldwide cost of fixing the "Millennium Bug" specifically to COBOL systems, because so much of the affected code, in finance and government above all, was written in it.

The fix worked. The systems kept running past midnight on the thirty-first of December nineteen ninety-nine. But Y2K also proved something that has shaped every decision about COBOL since: when code this old and this deeply embedded goes wrong, the cost of finding out is measured in the running of the world's banks, not in a support ticket.

8. The workforce cliff

The language survived Y2K. The people who know it are not surviving in the same numbers.

Industry surveys have placed the average age of a working COBOL programmer above fifty-five, and estimates in the trade press suggest roughly three-quarters of the current COBOL workforce could retire within a decade. IBM has responded by training more than one hundred and eighty thousand developers in COBOL through fellowship and training programmes run over more than a dozen years, aimed directly at that gap.

The scarcity has a price. Experienced COBOL specialists routinely earn salaries and contract rates well above the market average for other programming languages, simply because so few people can maintain what is running.

9. Why replace it, and why nobody fully has

Every large organisation running COBOL has, at some point, considered replacing it. Almost none have replaced all of it.

Rewriting a core banking or tax system means re-implementing decades of business rules that were never written down anywhere except in the code itself, and testing the replacement against every edge case the old system has quietly handled correctly since the nineteen eighties. A rewrite that gets even a small percentage of those rules wrong can miscalculate real payments to real people.

So the more common path is not replacement. It is coexistence. Newer languages get built around the COBOL core rather than instead of it. Translation tools convert COBOL logic into Java or another modern language. Increasingly, AI-assisted tools help a shrinking pool of specialists read and modify code that was never meant to still be running sixty-six years later.

10. Forwards, not backwards

COBOL is not a relic sitting untouched in a museum. It is live code, still processing real transactions today, still being patched, still being trained on, still being replaced one careful piece at a time rather than all at once.

That is not a story about a language stuck in the past. It is a story about an industry making one decision, project by project. Keep the plumbing that has not failed running for as long as it keeps not failing. Change it only where the cost of leaving it alone has grown larger than the risk of touching it.

Sixty-six years on, that calculation is still coming out the same way, for institutions that quite literally cannot afford to get it wrong.