If COBOL is so problematic, why does the US government still use it?

Some people think tens of millions of dead people are collecting Social Security checks. That’s not true. What’s really going on is people don’t understand its old, underlying technology. 

The saga of 150-year-old Social Security recipients is a tale that intertwines aging technology, government systems, and modern misunderstandings by the youthful Department of Government Efficiency (DOGE) IT people. At the heart of this story lies COBOL, a programming language that has been Social Security’s backbone for decades.

COBOL code and arcane standards

COBOL, or Common Business Oriented Language, was developed in the 1950s and has become a critical component of the Social Security Administration’s (SSA) IT infrastructure. The SSA maintains over 60 million lines of COBOL code, which powers its core business functions, including processing retirement and disability claims.

Also: The best AI for coding in 2025 (and what not to use)

One of COBOL’s peculiarities is its lack of a standardized way to store and work with dates. This limitation has led to programmers making up ways in government databases to represent dates. This also meant they came up with the use of placeholder dates for unknown information.

According to Manjeet Rege, data science and software engineering professor at the University of St. Thomas School of Engineering, one of the most common placeholder dates is May 20, 1875. Why that date? Because that’s the beginning of time according to the ISO 8601 time and date standard. 

Now, you may well ask why the standard makers picked that seemingly arbitrary date? The answer is it’s not arbitrary at all, just obscure. It’s the anniversary of the International Bureau of Weight and Measures creation date, aka the metric system. 

What that means in practice is that, in at least some cases, if someone applies for Social Security without a birth date, they’d automatically be assigned a birthdate of May 20, 1875, which is how we end up with 149+-year-old senior citizens.

That’s not the whole story, though. Thousands of programmers have worked on the Social Security system over the decades, and untold numbers of data entry clerks have posted dates into the system. The result has been, in a word, messy.

Also: I tested DeepSeek’s R1 and V3 coding skills – and we’re not all doomed (yet)

For example, a 2011 Social Security Inspector General analysis of data reported that “an abnormally large spike in the number of individuals with a YOB [Year of Birth] value equal to 1900.” I have no doubt this resulted from data entry clerks simply picking an easy date for someone who was very old. 

In addition, all Social Security records from before 1950 were originally kept on paper and microfilm and then brought over by hand. That left lots of room for human error. 

None of which gives would-be thieves much room to operate. You see, when you die and are buried or cremated, the funeral home should file a Statement of Death by Funeral Directors (Form SSA-721). There really is a form for everything! 

In addition, years before DOGE existed, the Social Security Administration (SSA) was already checking on extremely old citizens. This 2023 study found that while 18.9 million Social Security number holders were listed as being born in 1920 or earlier and didn’t have a death date recorded, only 44,000 were receiving benefits. In short, the records may be filled with errors, but only a comparative handful of accounts are still being paid out.

Also: How to use ChatGPT to write code: What it does well and what it doesn’t

Finally, since 2015, the SSA has had automated systems in place that automatically block payments to anyone older than 115. In short, there are no vampires out there getting Social Security payments.

It’s not just Social Security

In the coming weeks and months, we might see DOGE reporting finding “fraud” in government agencies where the real crime is out-of-date, badly-maintained software, and not any criminal intent. 

COBOL, you see, may be old, but it’s far from dead. According to the Government Accounting Office (GAO), numerous vital government systems still rely on legacy software and hardware. Some of these systems are more than 50 years old. 

These archaic systems include ones for the Department of Education for tracking students; the Department of Health and Human Services’ clinical and patient administration; and Medicare & Medicaid Services still uses COBOL-based systems for critical operations.

Also: The most popular programming languages (and what that even means)

Last but not least, the Internal Revenue Service (IRS) still uses COBOL for some of its critical systems. Altogether, the IRS still relies on approximately 160 COBOL applications. At the IRS’s heart is every taxpayer’s Individual Master File (IMF). This is written not just in COBOL but in IBM Assembler as well. This is, in no way, shape, or form, easy code to work with. Complicating matters further, the IRS uses multiple versions of COBOL, including IBM COBOL for OS/390 & VM, IBM Enterprise COBOL for zOS, and Micro Focus Visual COBOL for Eclipse.

You might think that IMF, which dates back to the early 1960s, is the oldest computer system. You’d be wrong. The Department of Defense’s computerized contract-management system, Mechanization of Contract Administration Services (MOCAS), is still with us after almost 67 years of service. That’s even older than the official release of COBOL itself. MOCAS was written in beta COBOL. 

In theory, the IMF was to be replaced by 2028. That was before DOGE cut 6,000 IRS employees out of the government agency’s approximately 82,990 employees.

This problem isn’t limited to just the Federal government. Forty-five of the 50 states and the District of Columbia still run COBOL systems. Many of you may remember when Covid first hit, and you couldn’t get unemployment checks. More than likely, your money was delayed because of over-burdened COBOL-based unemployment programs. 

Also: The rise and fall in programming languages’ popularity since 2016 – and what it tells us

None of this is COBOL’s fault. It may be old, but COBOL is still useful. Indeed, when you get cash from an ATM, 95% of the time you’re interacting with a COBOL program. Behind them, 43% of banking systems are written in COBOL, and 90% of banks still use some COBOL. It’s not just banks. Insurance companies also rely on COBOL. This old programming language will not be leaving us this decade, maybe not this century. 

Why? It’s not so much that COBOL itself is bad. It’s not. COBOL excels at efficiently processing large volumes of business data. Its syntax and structure are optimized for data manipulation and batch-processing tasks. The language is also great at organizing data and indexing it for fast, efficient operations. The result is a language that excels at data accuracy and reliability. That last quality has extended COBOL’s life for decades. 

The problem for the government COBOL-based programs boils down to the fact that there’s never been enough funding to update the legacy code. 

Replacing COBOL?

So, why not replace all the old code with new programs? It’s not that easy. In fact, it’s really hard but it can be done. Both the UK Department for Work and Pensions (DWP) and the New York Times managed to migrate away from mainframe COBOL in the last decade. 

Also: Brace yourself: The era of ‘citizen developers’ creating apps is here, thanks to AI

However, the sheer volume of COBOL code that needs modernizing is daunting. Estimates range from 220 billion to 800 billion lines of COBOL code still in use today. Decades of accumulated code, inconsistent programming styles, a lack of documentation, and inconsistent standardization make understanding and porting these systems difficult. To add to the complexity, legacy COBOL applications often contain business logic and processes intricately woven into the code.  

Frankly, I expect critical COBOL programs to run until the end of my days. It wouldn’t surprise me if COBOL software still matters at the end of the century. No, I’m not kidding. In the meantime, our failure to spend money to update our government’s IT infrastructure should be carefully scrutinized in the search for government waste.