Elon Musk has turned his attention to the Social Security Administration, the latest agency that his team of novice programmers has invaded for the apparent purpose of hobbling it. Wired magazine reported last week that the Department of Government Efficiency plans to replace the mainframes that power the agency’s mission and rebuild their functionality on new servers in a new programming language — with just a few months’ work.
Assuming Wired’s reporting is accurate, we know that such an effort will surely fail. The track record of decades of modernizations of thousands of software systems, in both the private and public sectors, makes that clear. This isn’t even an interesting-yet-flawed idea. It’s a hackneyed, clichéd bad idea that could only sound compelling to novice software developers. It’s like cooking a Thanksgiving turkey in 20 minutes by putting it in a blast furnace, or choosing to get measles instead of getting vaccinated against it: it sounds most convincing to the layperson who asks the fewest questions.
Critics complain that the COBOL programming language, widely in use in the SSA, is old and outdated. This is wrong.
The SSA delivered $1.3 trillion in benefits to 70 million beneficiaries in 2023, a testament to the quality of its infrastructure. The software that drives the SSA is the most critical part of that infrastructure. Like nearly all state and federal agencies, if the SSA’s specialized software doesn’t work, the agency is dead in the water. And as with other agencies, the SSA’s largest contracts are for the technical infrastructure that undergirds SSA’s mission, with firms such as IBM, Dell and Leidos being paid hundreds of millions of dollars to build and maintain the hardware and software that allow the agency to function. That might sound like a lot of money, but the agency’s overhead is legendarily low: administrative expenses come to just 0.5% of the total cost of the program, well below the overhead of 401(k) programs and most state and local government pensions.
Critics complain that the COBOL programming language, widely in use in the SSA, is old and outdated. This is wrong. While COBOL’s origins date to 1959, it’s an actively maintained programming language, with an updated standard published by the International Standards Organization in 2023. The advanced age of actively maintained languages is evidence of their sustainability and quality. Many “modern” languages are quite old: C is 52 years old, Python is 34 years old, and even JavaScript will turn 30 this year. COBOL remains so widely used in our financial system that 95% of ATM transactions rely on it. There are 220 billion lines of COBOL in use today. Why? Mostly because it’s really good at processing large amounts of business data.
Critics also complain that mainframes are antiquated in an era of cloud computing. In fact, mainframes are still in wide use throughout the public and private sectors. They are not the room-sized reel-to-reel machines of the 1960s, but instead sleek, modern machines that would turn any developer’s head. They excel anywhere that it’s important to have lots of processing power, high redundancy and the ability to muscle through big batches of data processing—precisely what the SSA needs.
Modernizing the SSA’s technical infrastructure is not a novel idea. The agency has continuously modernized its systems since 1982, and published a new digital modernization strategy just last year. That’s because one-time modernizations, at best, succeed only for a brief time. Without ongoing modernization, the infrastructure quickly will become old again. Continuous modernization does not necessarily mean replacing COBOL or moving the whole system off mainframes. It means identifying and prioritizing the most urgent needs of the system’s users and building whatever technical infrastructure is necessary to make that happen. It is entirely possible that COBOL on mainframes is the correct infrastructure for many of the needs of the Social Security Administration.
The important thing about the existing SSA technical infrastructure is that it works! Those 70 million people get their $1.3 trillion in monthly payments, which allow them to pay their rent, buy food, afford medications and give birthday presents to their grandkids. Commerce Secretary Howard Lutnick’s mother may not worry about getting her check — likely because her son is a billionaire — but to many of those 70 million people, their monthly check is all that’s keeping them housed, clothed and fed.
What could be the legitimate purpose of this incredibly dangerous operation?
If Twitter accidentally goes down for a few hours, nothing terrible happens. But if just one person misses a Social Security payment, that could drop the person off a financial cliff. Replacing the SSA’s core infrastructure with an entirely new system all at once is performing a high-wire act without a net, only it’s not DOGE staffers who risk falling — it’s the Social Security beneficiaries who depend on that social safety net.
Complex systems theoretically reflect a complex set of documented rules — in this case, laws, regulations and policies — but, in practice, there are additional rules that are encoded only in the software, documented nowhere else. To the inexperienced software developer, it can seem self-evident that you can replace an old system with a new one by using the documented, but the experienced software developer knows that’s a trap.
Replacing COBOL is a special challenge, for a reason generally known only to experienced COBOL developers: math works differently in COBOL. It handles decimals unlike any other programming language, which is particularly important for large financial systems working at the scale of the SSA. What COBOL might calculate as 1,000.99, Java might calculate as 1,000.98. Neither number is wrong in a mathematical sense, but for an accounting and payment system designed around decades of COBOL-based math, the Java-based answer is functionally wrong. For a system making 840 million financial transactions annually, such a small difference in math can quickly spiral into a disaster.
Even if we imagine that there was a complete, successful replacement of the COBOL mainframes with a different programming language and different servers, it’s not at all clear that anybody would benefit. The existing systems get the job done. And the mainframes are just for the backend of the system that handles data storage, tracking and accounting. The front end — the parts of the system that the public sees — would be left untouched by such a modernization. If the existing backend functions fine, and the front end doesn’t require modernization, what could be the legitimate purpose of this incredibly dangerous operation?
There are two possible explanations: either the DOGE programmers are so inexperienced and cocksure that they think this can actually work, or this is a cover for doing serious damage to the Social Security system. As a nation, we cannot afford the risk that either of these explanations are right, or the even greater and more likely risk: that both explanations are right.
That the SSA’s systems are old is not evidence of them being problematic — on the contrary, it is evidence of their reliability and sustainability. There is no “one neat trick” that will make a complete overhaul possible in the span of a few months. Hard things are hard. DOGE’s effort is likely to fail and threatens to bring down Social Security along with it.