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.”
