COBOL: The Language That Refuses to Die

The Phone Call from New Jersey

On April third, twenty twenty, the governor of New Jersey held a press conference about unemployment claims. The state's systems were overwhelmed. Hundreds of thousands of people had been laid off in a single week. The unemployment insurance system, which normally processed a few thousand claims per month, was being asked to handle forty thousand per day. And it was breaking. The governor, a man named Phil Murphy, stood at the podium and said something that made every tech journalist in the country sit up straight.

We have systems that are forty years old. There'll be lots of postmortems, and one of them on our list will be how the heck did we get here when we literally needed COBOL programmers.

COBOL. Common Business-Oriented Language. A programming language designed in nineteen fifty-nine by a committee led by a Navy rear admiral named Grace Hopper. A language that most computer science graduates today have never seen, never studied, and certainly never written. A language that the tech industry has been declaring dead since approximately nineteen eighty-five. And a language that, at the moment the governor made that plea, was processing ninety-five percent of all ATM transactions on Earth, eighty percent of all in-person financial transactions, and the vast majority of government benefits processing in the United States.

The phone call from New Jersey went out like a distress signal. We need COBOL programmers. Immediately. The problem was not that COBOL was broken. The problem was that nobody who knew how to modify it was available. The people who wrote those systems had retired. Some had died. The ones who were still alive were in their seventies and eighties, and they were being asked to come out of retirement to fix unemployment systems during a global pandemic.

The Admiral Who Spoke English

Grace Hopper did not invent COBOL alone, but she is the reason it exists. In the late nineteen fifties, Hopper was already a legend in computing. She had worked on the Harvard Mark One during World War Two. She had coined the term "debugging" after finding an actual moth stuck in a relay. And she had developed the first compiler, a program that translated human-readable instructions into machine code, at a time when most people in computing thought such a thing was impossible.

Hopper's insight was simple and radical. She believed that programming languages should look like English, not like mathematics. The prevailing view in the nineteen fifties was that computers were mathematical machines and should be programmed in mathematical notation. Fortran, which appeared in nineteen fifty-seven, used algebraic expressions. Assembly language used cryptic mnemonics. Hopper thought this was insane. Most of the people who needed to use computers were not mathematicians. They were businesspeople, accountants, government administrators. They needed to express things like "if the balance is less than zero, print a warning" in something that resembled the language they already spoke.

I kept telling them that we could write programs in English and the computers would translate them. They said I was crazy. They said computers couldn't understand English. I said I'd already done it.

In nineteen fifty-nine, the Department of Defense convened a committee called CODASYL, the Conference on Data Systems Languages, to create a common business programming language. Hopper was one of the key technical advisers. The language they produced was deliberately verbose. Where a modern programmer might write a function call, a COBOL programmer would write "MOVE CUSTOMER-BALANCE TO PRINT-LINE." Where Python uses indentation, COBOL uses paragraph names. Where JavaScript uses curly braces, COBOL uses words like PERFORM and UNTIL and STOP RUN.

The verbosity was not a design flaw. It was the entire point. A COBOL program was supposed to be readable by a business manager, not just a programmer. The code was the documentation. And for decades, in government offices and bank back-offices and insurance companies, this worked exactly as intended. The people who maintained the systems could read the code because the code read like a memo.

The Quiet Takeover

COBOL did not become the backbone of global finance through technical superiority. It became the backbone through institutional adoption and sheer staying power. In the nineteen sixties, the Department of Defense mandated that all data processing systems purchased by the federal government must support COBOL. This single decision cascaded through the entire economy. Banks that did business with the government adopted COBOL. Insurance companies that dealt with those banks adopted COBOL. Corporations that needed to file taxes with the government adopted COBOL.

By nineteen seventy, COBOL was the most widely used programming language in the world. By nineteen eighty, there were an estimated two hundred billion lines of COBOL code in active production. Two hundred billion. To put that in perspective, the entire Linux kernel today is about thirty-six million lines. The world's COBOL codebase was, and remains, larger than most people can comprehend.

And here's the critical detail. Those systems were not prototypes or temporary solutions. They were built to run payroll, process insurance claims, manage pension funds, clear bank transactions. They were built by careful people who expected the code to run for years, maybe decades. They were tested exhaustively. They were documented, at least initially. And then they were left to run.

And run they did. Year after year, decade after decade. The COBOL batch job that processes Social Security payments in the United States has been running, in various forms, since the nineteen seventies. It processes sixty-five million payments per month. It has never missed a payment. The system that clears transactions between Federal Reserve banks runs COBOL. The system that manages Medicaid claims for three hundred and thirty million Americans runs COBOL. These are not legacy systems in the sense that they're outdated. They are legacy systems in the sense that they are the foundation on which everything else is built.

The Demographic Time Bomb

The problem with COBOL is not the language. The language is fine. It does what it was designed to do, reliably, at massive scale, with minimal resources. The problem is the people.

The last generation of programmers to learn COBOL in university graduated in the late nineteen eighties. After that, computer science departments pivoted to C, then C plus plus, then Java, then Python. COBOL was old-fashioned. It was unglamorous. It ran on mainframes, and mainframes were supposedly dying. Nobody wanted to learn a language associated with their parents' computer room.

But the systems kept running. And the people who maintained them kept aging. By twenty-ten, the average age of a COBOL programmer in the United States was fifty-five. By twenty-twenty, it was sixty-one. The workforce was literally dying. Not metaphorically. Actually dying. And the systems they maintained were not getting replaced because replacing them was terrifyingly expensive and risky.

The Commonwealth Bank of Australia spent five years and seven hundred fifty million dollars replacing a single core banking system. The state of California spent three hundred million dollars and seven years trying to replace its payroll system before giving up and going back to COBOL. The United Kingdom's National Health Service spent twelve billion pounds on a modernization program that was eventually cancelled, the largest civilian IT failure in history. The COBOL systems they were trying to replace are still running.

This is the pattern. A government or corporation announces a modernization initiative. Consultants are hired. Requirements are gathered. Architectures are designed. Years pass. Budgets balloon. And eventually, someone realizes that the forty-year-old COBOL system handles edge cases that nobody documented, that nobody remembers, and that the new system can't replicate without someone who understands the original code.

The Retirement Hotline

I retired in twenty-twelve. I was sixty-seven. I thought I was done. Then in twenty-twenty, my old employer called. Then a staffing agency called. Then the state government called. They needed me to modify the unemployment system because nobody else understood the file layouts.

When Governor Murphy made his plea for COBOL programmers, IBM responded within days. They set up a volunteer portal and recruited retired COBOL developers. Within a week, they had over a thousand volunteers. The youngest was in his fifties. Many were in their seventies. Some had not written COBOL in twenty years.

The volunteers were not being asked to do anything exotic. They were being asked to change a batch processing parameter, modify a file layout to accommodate a new field, increase a buffer size to handle higher volumes. These are trivial tasks for someone who knows the system. They are impossible tasks for someone who doesn't, because the documentation is incomplete, the institutional knowledge is in someone's head, and the code itself is the only reliable record of what the system actually does.

This is the real crisis. Not that COBOL is old. Not that it's ugly. Not that it's unfashionable. The crisis is that the knowledge of how these specific systems work, the peculiarities, the workarounds, the undocumented business rules embedded in paragraph names and conditional statements, is stored in human brains that are retiring and dying faster than the knowledge can be transferred.

The Invisible Infrastructure

There's a concept in software engineering called the Lindy effect. The idea is that the longer a technology has survived, the longer it is likely to continue surviving. By this measure, COBOL is one of the most durable technologies in human history. It has been in continuous production use for sixty-seven years. The average Silicon Valley startup lasts four years. The average enterprise software platform lasts maybe fifteen before being replaced. COBOL has outlived eight generations of supposedly superior replacements.

Today, an estimated eight hundred billion dollars of commerce flows through COBOL systems daily. Ninety-five percent of ATM swipes touch COBOL code. Eighty percent of in-person financial transactions use it. There are still two hundred and twenty billion lines of COBOL in active production, and about two billion new lines are written each year. Not maintained. Written. New COBOL, in twenty twenty-six, for systems that will probably still be running in twenty fifty.

The programmers who write and maintain this code are the most invisible workforce in technology. They don't speak at conferences. They don't have Twitter followings. They don't publish on GitHub. They work in government offices and bank data centers and insurance company basements, modifying job control language and tweaking copybooks. They keep the world's money moving, and almost nobody knows they exist.

The Grace Hopper Paradox

Grace Hopper died in nineteen ninety-two at the age of eighty-five. She was the oldest active-duty officer in the United States Navy at the time of her retirement. She spent her final years giving lectures about the future of computing, always carrying a piece of wire eleven point eight inches long. That was the distance light travels in one nanosecond. She used it to explain why computers needed to get faster and smaller.

[serious] The paradox of her legacy is this. She designed COBOL to be readable, to be maintainable, to be a language that business people could understand and that systems could run for years without constant modification. And it worked. It worked so well that the systems built in her language are still running decades after the people who built them are gone. The language she created to be understandable became the language that nobody understands, not because it's hard, but because nobody bothered to learn it.

Somewhere right now, a COBOL batch job is processing tonight's bank settlement. It will move trillions of dollars between institutions. It will not crash. It will not timeout. It will not throw an unhandled exception. It will do exactly what Grace Hopper's committee designed it to do in nineteen fifty-nine, which is process business transactions reliably, in a language that reads like English, on hardware that was supposed to be obsolete thirty years ago.

The AS four hundred would understand. Some things are built to last. The question is whether anyone will be left who knows how they work.