COBOL Is the Asbestos of Programming Languages

Early in the Covid-19 pandemic, the governor of New Jersey made an unusual admission: He’d run out of COBOL developers. The state’s unemployment insurance systems were written in the 60-year-old programming language and needed to be updated to handle the hundreds of thousands of claims. Trouble was, few of the state’s employees knew how to do that. And the crisis went beyond New Jersey, just one of many states that depended on these unwieldy systems. By one rough calculation, COBOL’s inefficiencies cost the US GDP $105 billion in 2020.

You might think New Jersey would have replaced its system after this—and that Covid was COBOL’s last gasp. Not quite. The state’s new unemployment system came with a number of quality-of-life improvements, but on the backend, it was still made possible by a mainframe running the ancient language.

COBOL, short for Common Business-Oriented Language, is the most widely adopted computer language in history. Of the 300 billion lines of code that had been written by the year 2000, 80 percent of them were in COBOL. It’s still in widespread use and supports a large number of government systems, such as motor vehicle records and unemployment insurance; on any given day, it can handle something on the order of 3 trillion dollars’ worth of financial transactions. I think of COBOL as a kind of digital asbestos, almost ubiquitous once upon a time and now incredibly, dangerously difficult to remove.

COBOL was first proposed in 1959 by a committee comprising most of the US computer industry (including Grace Hopper). It called for “specifications for a common business language for automatic digital computers” to solve a growing problem: the expense of programming. Programs were custom-written for specific machines, and if you wanted to run them on something else, that meant a near-total rewrite. The committee approached the Department of Defense, which happily embraced the project.

COBOL’s design set it apart from other languages both then and now. It was meant to be written in plain English so that anybody, even nonprogrammers, would be able to use it; symbolic mathematical notation was added only after considerable debate. Most versions of COBOL allow for the use of hundreds of words (Java permits just 68), including “is, “then,” and “to,” to make it easier to write in. Some have even said COBOL was intended to replace computer programmers, who in the 1960s occupied a rarified place at many companies. They were masters of a technology that most people could barely comprehend. COBOL’s designers also hoped that it would generate its own documentation, saving developers time and making it easy to maintain in the long run.

But what did it even mean to be readable? Programs aren’t books or articles; they’re conditional sets of instructions. While COBOL could distill the complexity of a single line of code into something anybody could understand, that distinction fell apart in programs that ran to thousands of lines. (It’s like an Ikea assembly manual: Any given step is easy, but somehow the thing still doesn’t come together.) Moreover, COBOL was implemented with a piece of logic that grew to be despised: the GO TO statement, an unconditional branching mechanism that sent you rocketing from one section of a program to another. The result was “spaghetti code,” as developers like to say, that made self-documenting beside the point.

Plenty of computer scientists had issues with COBOL from the outset. Edsger Dijkstra famously loathed it, saying, “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” Dijkstra likewise hated the GO TO statement, arguing that it made programs nearly impossible to understand. There was a degree of real snobbishness: COBOL was often looked down on as a purely utilitarian language that was intended to solve boring problems.

Jean Sammet, one of the original designers, saw it differently—the language simply had the complicated task of representing complicated things, like social security. Or as another defender wrote, “Regrettably, there are too many such business application programs written by programmers that have never had the benefit of structured COBOL taught well.” Good COBOL was indeed self-documenting, but so much depended on the specific programmer. Fred Gruenberger, a mathematician with the Rand Corporation, put it this way: “COBOL, in the hands of a master, is a beautiful tool—a very powerful tool. COBOL, as it’s going to be handled by a low-grade clerk somewhere, will be a miserable mess.”

None of this stopped COBOL’s widespread adoption, of course. That the Department of Defense put its finger on the scale and required COBOL compilers in most of the machines it ordered certainly helped. No computer manufacturer at the height of the Cold War wanted to miss out on those federal contracting dollars. In the end, COBOL succeeded at two of its most important goals: It was truly machine-independent and could proliferate rapidly. Its reliance on fixed-point and not floating-point arithmetic (if you know, you know) made COBOL ideal for financial applications, which is why it’s everywhere in the financial sector.

But as New Jersey learned in 2020, updating COBOL for the modern age presents real challenges. Sammet admitted a key mistake in the early design: no “parameterization.” Different parts of a program were broken into modules, but they couldn’t pass data to each other, so they had to share everything, which meant that changes in one place could affect the whole program. Or cause millions of dollars to disappear in a flash. Or shut down people’s Social Security payments.

Today, companies like IBM are trying to sell COBOL conversion tools that are powered by generative AI. (At one point, DOGE was promising to use one such tool to completely rewrite the Social Security Administration’s codebase in a matter of months. The effort seems to have stalled.) But we may be caught in a bind. Simply converting COBOL to, say, Java results in “JOBOL,” a confusing mishmash that mimics the structure of COBOL but with none of its readability. I’m not convinced by many of these AI tools. As with COBOL, they promise a streamlined, anyone-can-do-it efficiency. Look what happened there.