Government software development is a curious business.
When I was a student at the Naval Postgraduate School, I wrote a paper called “There is a Lot of Money to be Made Writing Bad Software for the Federal Government.”
The general idea is that the incentives to write good software aren’t nearly as strong as those nudging you to write it poorly. First, the projects are usually huge and done on a “cost plus” basis. That is, a company estimates how much the project will cost, and submits a bid based on that cost plus a profit margin. The idea is that competing companies will work to get their development costs down and minimize their profits to become the lowest bidder.
Now, the lowest bid doesn’t always win, but generally it does. So the incentive is strong to bid as low as one can dare.
Typically, then, the winning bidder gets to work, and they soon realize that they won’t possibly be profitable in the endeavor unless they build quickly, cut corners, and generally do the minimum work required to meet the specification, often with sub-sub-optimal results.
Ineptness rewarded
Guess what happens next? When the delivery day arrives, everyone is shocked when the project isn’t finished and what is done isn’t very good. So the government sighs to itself and puts out another bid to get everything working.
Well, who is best suited to “fix” the project? Naturally, the company that built it! So they are very often awarded an additional contract to “correct” the problems of the first effort, and so it goes.
Thus, software development organizations can win millions of dollars in government contracts for writing bad software and never delivering good, working code.
It is way more complex than that, and the government does get systems working. But the underlying incentives are not designed to produce efficient and effective outcomes. The profit motive drives bad work, not excellent work.
In the defense of these contractors, government systems are often huge and complex and have requirements documents thousands of pages long.
So when I heard that Elon Musk and his DOGE team are going to rewrite the COBOL-based system that runs Social Security in a few months, I just shook my head and gave a wry chuckle. Sure they are.
The biggest pile
Let’s start with the notion of rewriting a working system. Sure, it’s probably a huge pile of mud, among the hugest of piles of mud. But it is, more or less, working. And the wisdom of taking a working system, which has embedded within it all of the knowledge of decades of development and requirements of the system, and rewriting it to contain all of that inscrutable, unknowable corporate knowledge is, to put it delicately—quite insane.
I won’t touch the political side of this whole thing (not with a 15-foot pole) but I will fearlessly assert this: The DOGE team members don’t have even the slightest idea what the requirements are for the US Social Security software system. They don’t have the slightest idea what they don’t know. Much of that knowledge is embedded in the code and just runs—sending out checks, processing applications, and generally keeping things running. How anyone is going to read all of that COBOL code, understand it, and translate it into a Python application (or whatever) is beyond me.
Look, I get it. I’ve never met a software developer who didn’t think they could take an existing working system that looks like a 200-car train wreck full of kitchen appliances and turn it into a Japanese bullet train. But the industry has known for decades that rewriting a system from scratch is never the right solution. Asking a team to rewrite what might be the single most complex and important system in the entire country seems the very definition of fraught with peril.
So no, they won’t rewrite Social Security in a few months. They’ll spend a few months learning why the last 40 years happened the way they did—if they’re lucky. And if this train does start rolling—and let me say very clearly that it should unquestionably remain in the station—we’re all going to find out what happens when you run a 200-car train full of kitchen appliances off the rails.