In the early months of the Covid-19 pandemic, as the global economy shuttered and unemployment claims reached unprecedented heights, New Jersey Governor Phil Murphy made a public appeal that sounded more like a call for a historical society meeting than a modern administrative emergency. He announced that the state was in desperate need of volunteers who knew how to code in COBOL. The state’s unemployment insurance systems, designed and implemented decades prior, were buckling under the weight of hundreds of thousands of new claims. The infrastructure was written in a 60-year-old programming language that few active developers understood, creating a bottleneck that threatened the financial security of countless citizens.
New Jersey was far from an isolated case. From Connecticut to Kansas, state governments found themselves hamstrung by "legacy" systems that had been running quietly in the background for over half a century. The inefficiencies of these aging frameworks were not merely a technical nuisance; they carried a staggering economic price tag. According to a 2020 analysis by the Brookings Institution, the friction caused by outdated COBOL-based unemployment systems contributed to a loss of approximately $105 billion in the United States GDP that year alone. Despite the high-profile nature of these failures, the anticipated "last gasp" of COBOL never arrived. When New Jersey finally updated its system, the modern user interface and quality-of-life improvements were largely cosmetic. On the backend, the core processing was still powered by a mainframe running the same ancient language.
The Invisible Foundation of Global Finance and Governance
COBOL, an acronym for Common Business-Oriented Language, holds the distinction of being the most widely adopted computer language in history. By the turn of the millennium, it was estimated that of the 300 billion lines of code in existence, roughly 80 percent were written in COBOL. While modern developers often favor Python, Java, or Rust, COBOL remains the silent engine of the global economy.
On any given business day, COBOL-based systems facilitate approximately $3 trillion in financial transactions. It underpins the vast majority of credit card swipes, ATM withdrawals, and person-to-person bank transfers. Beyond the private sector, it is the backbone of essential government functions, including motor vehicle records, Social Security administration, and the Internal Revenue Service’s Individual Master File (IMF)—the oldest transition system in the federal government.
The ubiquity of the language has led many technologists to describe it as "digital asbestos." Like the physical mineral, COBOL was once seen as a miracle solution—reliable, standardized, and incredibly durable. However, decades later, it has become a substance that is dangerously difficult and prohibitively expensive to remove. The systems are so deeply integrated into the plumbing of modern life that pulling them out risks a systemic collapse.
A Chronology of COBOL: From the Pentagon to the Mainframe
The origins of COBOL date back to May 1959, when a committee of computer experts, including the legendary Rear Admiral Grace Hopper, convened at the Pentagon. The group, known as the Committee on Data Systems Languages (CODASYL), sought to create a "common business language" that could run on any manufacturer’s hardware. At the time, programming was a fragmented and expensive endeavor; code written for an IBM machine would not work on a Remington Rand or a Honeywell computer.
The Department of Defense, facing ballooning costs for custom software, threw its weight behind the project. By 1960, the first specifications for COBOL were released. The language was designed with a radical philosophy: it was meant to be readable by human beings, not just mathematicians.
Unlike the symbolic, abstract notation of scientific languages like FORTRAN, COBOL utilized plain English syntax. It incorporated hundreds of reserved words—such as "ADD," "MOVE," and "COMPUTE"—intended to make the logic of a program transparent to managers and auditors. Some of its creators even harbored the ambitious, if ultimately misplaced, hope that COBOL would eventually eliminate the need for professional programmers altogether, allowing business executives to write their own instructions for the "automatic digital computers" of the era.
The Technical Architecture and the "Spaghetti Code" Dilemma
The design of COBOL set it apart from the languages that followed. While a modern language like Java permits only 68 reserved keywords, COBOL utilizes hundreds, including common English connectors like "is," "then," and "to." This verbosity was a double-edged sword. While it made individual lines of code easier to read, it often obscured the larger structure of the program.
A central point of contention in COBOL’s architecture was the "GO TO" statement. This was an unconditional branching mechanism that allowed a program to jump from one section of code to another far-removed section. In the hands of a disciplined developer, this was a powerful tool; however, in massive, multi-thousand-line programs, it led to what developers call "spaghetti code." The logic became a tangled web of jumps and redirects that was nearly impossible to map or debug.
This lack of structure drew the ire of academic computer scientists. Edsger Dijkstra, a pioneer in the field of structured programming, was famously vitriolic in his assessment. In 1975, he wrote, "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." Dijkstra and his contemporaries viewed COBOL as a crude, utilitarian tool that lacked the mathematical elegance required for "true" computer science.
Conversely, defenders of the language, such as original designer Jean Sammet, argued that COBOL was simply a reflection of the complex world it was built to manage. Business logic—calculating payroll taxes, processing insurance claims, or managing social security benefits—is inherently messy and full of exceptions. COBOL was built to handle that messiness at scale. As mathematician Fred Gruenberger noted, "COBOL, in the hands of a master, is a beautiful tool… COBOL, as it’s going to be handled by a low-grade clerk somewhere, will be a miserable mess."
The Talent Gap and the Economic Risk of Obsolescence
The persistence of COBOL has created a unique labor crisis in the 21st century. The generation of programmers who built these systems in the 1970s and 80s has largely reached retirement age. As they leave the workforce, they take with them the institutional knowledge required to maintain the world’s most critical infrastructure.
Universities have long since removed COBOL from their computer science curricula, favoring modern web development and data science. This has left a massive talent vacuum. When a state agency or a major bank needs to update its COBOL backend, they often find themselves hiring retired developers back as high-priced consultants, sometimes paying hundreds of dollars an hour for their expertise.
The risk of this "black box" architecture is significant. Many organizations are operating on code that no living employee fully understands. When a bug occurs, or when a policy change requires a logic update (such as the sudden shift in unemployment rules during the pandemic), the results can be catastrophic. The sheer volume of transactions handled by COBOL—$3 trillion daily—means that even a minor glitch can have global economic repercussions.
Implications and the High Cost of Modernization
Why, then, do organizations not simply rewrite their code in a modern language? The answer lies in the sheer scale and risk of the undertaking. A typical "rip and replace" project for a major bank’s core system can cost billions of dollars and take over a decade to complete.
In 2012, the Commonwealth Bank of Australia completed a modernization project that took five years and cost more than $1 billion. Many other institutions have attempted similar migrations only to abandon them after ballooning costs and technical failures. For a government agency or a financial institution, the risk of a system outage during a migration is often viewed as more dangerous than the risk of staying with a 60-year-old language.
However, the tide may finally be turning, not through manual rewrites, but through artificial intelligence. In 2023, IBM announced the "watsonx Code Assistant for Z," a generative AI tool designed to translate COBOL into Java. By using AI to automate the refactoring of legacy code, IBM hopes to provide a bridge for organizations to modernize their systems without the manual labor of a dwindling workforce.
Conclusion: The Endurance of the Mainframe
The story of COBOL is a testament to the longevity of well-built, if unfashionable, engineering. While it is often mocked as a relic of a bygone era, it remains one of the most successful pieces of technology ever devised. It has outlived dozens of "superior" languages and survived the transition from vacuum tubes to the cloud.
The 2020 crisis in New Jersey served as a wake-up call, but it also highlighted a fundamental truth of the digital age: our modern world is built on top of geological layers of software. We live in a high-speed, digital society, but beneath the sleek apps and touchscreens, the fundamental logic of our economy is still being processed by the steady, rhythmic English sentences of COBOL. As long as the cost and risk of replacement outweigh the cost of maintenance, the "digital asbestos" of the 1960s will continue to run the world of the 2020s and beyond.
About the Author
