Doge Plans to Rebuild SSA Codebase in Months
wired.com
wired.com
Rewriting in something where engineers are cheaper and that can use commodity/cloud servers probably looks quite good on paper Vs paying IBM in blood.
So goes almost every project that wants to rewrite a giant legacy system from scratch. In reality the number of developer hours will massively eclipse the price you'd have paid those hard to find COBOL engineers.
But doing that would require the DOGE folks to admit that they don't actually know everything and need to defer to someone with more knowledge. So it can't possibly be allowed.
This was probably kicked off by someone with power seeing how much IBM were charging for support/consultants etc. "Whaaaa? IBM want how much?"
On the other hand while I think it is a bit of a stupid idea to migrate off/rewrite for no reason other than "fuck you IBM", there probably comes a time when it does make sense to migrate - there are often hallmarks of this in old legacy systems where you need to do a LOT of work just to keep things running.
Typical examples are: really hard to recruit/retain people who know the technology, difficult to change things where the use-case does something the original designers did not anticipate, decades of tech-debt that makes people scared to change anything, endless patching of security fixes, lots of "glue-work" trying to interface the legacy systems with more modern things (think database drivers, automation tooling etc etc).
If it is hard to maintain a legacy system today, its going to be even harder in 10 or 20 years. "If it aint broke don't fix it" is valid, but in IT systems (with endless security vulns, endless changes to data legislation and sovereignty controls etc) you cant stand-still and leave things alone if it is a connected system dealing with people's personal data/finances/health/etc.
Somewhere sooner or later you're going to need to pull the trigger and sustain your business by investing in new technology rather than pouring more and more and more money into keeping a legacy system that is no longer fit for purpose. It will hurt sure, but sometimes you have to do it. Just do it carefully and in a realistic way (timelines, testing, slow-migration path etc)
It will make the initial launch of healthcare.gov look like a paradise of puppies and flowers.
Generally people choose technology that’s going to maximize their prospects in terms of employment. Maybe that is specializing in COBOL, systems and tech around it, and higher level abstractions that inevitably come along. For me that seems risky in terms of time investment, even more so in todays market, but I could be very wrong.
https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf
> Yet, we place extraordinary demands on an installed base of technology that is increasingly showing its age. Most of our core systems are over 30 years old and some embedded software components are older. Over the years, newer technologies have been integrated with these legacy systems without a fundamental redesign of the system and enterprise environment within which it operates. Today, the cost of operating in this legacy environment is expensive. Front- line SSA employees are finding these systems increasingly difficult to use, and members of the public are not getting the self-service opportunities they have come to expect based on their experience with commercial enterprises. Furthermore, systems engineers with legacy system expertise are retiring from SSA at an increasing rate. Replacing them with similarly skilled staff is also increasingly difficult in the current job market.
Let me introduce you to an IBM salesperson who knows you have no option apart from renew those contracts on the mainframe and COBOL consultants :)
Which of the unpaid 60+ workhours/week youths that Elon is sending in will stay on the project after shipping 1.0 ?
So when people say "all the COBOL programmers are retiring!", they're completely missing the problem. The language isn't the problem.
The problem is the design of the software written in COBOL, z/OS itself, and the operators that defend its design. The software has so much dark matter due to tech debt, partially due to age, partially due to vintage. z/OS has tech debt, due to designs for a different era being carried forward. Manual processes that should have safety guards and technical limitations abound.
But that's not to say DOGE should be trying to rewrite this stuff. Not on their schedule and not with their staff. Because it will create bugs. The same reason this software persists.
https://en.wikipedia.org/wiki/Misclassification_of_employees... https://en.wikipedia.org/wiki/Wage_theft
Using a language with no real community support and a very small available skilled workforce has massive negative effects on cost and productivity (i.e., the ability to deliver changes at reasonable cost, in reasonable timeframes, and with reasonable success).
You don't want to have something that people could be taught to operate, you want something where skill is a commodity and competition is sprawling. COBOL fails on these parameters, and therefore it is "legacy and bad".
You can replace COBOL in the above with any language having insufficient contemporary adoption.
That workforce is a small retiree club at this point, with financial institutions panicking and trying to promote COBOL and push it into computer science programs.
"Steadily deliver" is not a quality you can blanket assign to a group of people, and sounds more like an excuse for poor performance. The only quality one can assign to a small group of people will be lack of competition, which is purely about numbers, although that itself does not mean there won't be good developers in the group - just that that there is a lack of stimuli to grow the baseline.
Total embedded devs are around 2-2.5 million, but embedded driver devs are a much smaller subset. Hard to find numbers but probably around again 200,000 full time experienced so roughly the same amount.
You are making a false comparison. Even if we assume the number is correct, you're making a false comparison - COBOL is a language, "embedded drivers" is a software component. The equivalent to your COBOL number is all C/C++ developers.
Looking at some random online statistics like you did, COBOL is at 0.7% usage in 2024 vs. 20.3% for C and 23% for C++. Is that statistic credible? No, but neither is yours, and what matters is that COBOL doesn't.
Compare language or language, or component to component.
(Not to mention that "embedded driver developer" is not s category I'd ever make - half of what an embedded developer does would be classified as "drivers", and that term is only really used for non-embedded.)
Compare use case to use case, not language to language. You say if XYZ doesn't have developers, it shouldn't be used. Now you are saying 'but for your embedded, other people can be trained up'. Guess what, we can train up COBOL developers MORE easily than embedded driver devs. Your argument doesn't make any sense. By your argument we should not build systems around embedded drivers.
I've know embedded driver developers and you are completely wrong. They print money. CISCO had to bring my acquaintance back multiple times because again it's such a niche field and no one could do what he did. Same with my buddy that did washing machines. Same with my buddy that did street lights. It is a small subset that do the drivers. Totally relevant to the discussion of 'Can we afford to be dependant on such a niche field'. And the answer is 100% yes, we can.
Then you are comparing "bank account interest and debt systems" to "embedded drivers".
Or "tax systems" to "embedded drivers".
Or "insurance policy engines" to "embedded drivers", etc.
COBOL is not a use-case, and all of the above could be done in any language. If we are discussing the qualities, ease of training , workforce availability and overall viability of COBOL, it is against the qualities, ease of training, workforce availability and overall viability of other languages.
> We can train up COBOL developers MORE easily than embedded driver devs.
And we can train up web devs more easily than embedded driver devs.
Your argument makes no sense, as it is a false dichotomy. It also entirely misses the point that I stated earlier, that a company does not want to be able to train developers, they already trained developers to be in abundance in the market.
> I've know embedded driver developers and y you're completely wrong
I work in embedded (nowadays audio and display tech), and with driver development (to make said embedded devices useful, previously for high performance datacenter network equipment), and you're completely wrong.
Not to mention delusional regarding COBOL to the point of being a suspect of IBM employment. The only still relevant quality of COBOL is that it does not self combust so we can take our time with replacing it with something contemporary and financially sensible.
You claimed the COBOL ecosystem is too small to depend on. I pointed out that the embedded driver ecosystem is similarly small, yet we rely on it all the time. That’s a valid comparison as both involve small pools of specialists, niche tooling, long lived systems, and a steep learning curve. When I say “ecosystem,” that’s what I mean, not “tax systems” or “insurance policy engines,” which aren’t standalone developer ecosystems in the same way. Equating those with actual engineering ecosystems like COBOL or embedded drivers doesn’t really hold up.
Since you say you work in embedded then you should be well aware that embedded driver developers form a highly specialized subset, often with deep platform specific expertise and niche tooling. It is, in fact, easier to train a developer to work on enterprise COBOL systems than to become effective in low-level driver development. That’s not controversial it’s backed by experience across industries.
As for suggesting I must work for IBM because I don’t agree with your framing that’s not a serious argument. It’s not grounded in facts or reason, and doesn’t contribute anything meaningful to the discussion.
If you’re interested in debating the actual points, I’m happy to continue. If not, I’ll leave it here.
Throw away the codebase: no, until you have a well-working, battle-tested replacement. I mean, yes, it's possible to do, and you can even run e.g. Java under z/OS on the same in-house mainframe hardware because you can't trust the public cloud. But you still have to do the massive work of reverse-engineering the ancient, scantly documented Cobol codebase, write a modern replacement, cover a ton of corner cases, run in in prod as a shadow that does all the same work, and comparing the results with the load-bearing Cobol codebase, and switch over very carefully.
Depending on the size of your codebase, the complexity of your processes, the strength of your need for change, and the quality of your engineering org, the above may be a very costly process. Few managers are comfortable to approve such a large cost without a very clear return on this investment. Hence we'll see Cobol running for a few decades more.
When I'd started working with them it was on the 20 year old C++ engine that ran everything.
Even at that time there was large team 'rewriting' it in Java. That team was dissolved about 2 years later.
During the course of my employment two more large teams were spun up to do a rewrite and then came crashing down after a year or two.
I hadn't seen my coworkers for about 7 years. Naturally they were still working on the C++ code. Naturally they'd seen two more rewrite teams come and go while I'd been gone.
I'm not sure why I'm bringing this up......
And if they're actually serious and not just venting, it's also customary calibrate downward how much you trust their judgements.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
IIRC EBay rewrote their backend three times. It was not because the previous version was wrong, but because they were growing and changing, so a new backend was needed anyway to tackle that. They were and are doing fine.
Twitter rewrote their codebase from Ruby on Rails (the endless source of fail whales) to a completely different platform, again due to the huge growth. Technology-wise, they are doing pretty fine.
Facebook rewrote Messenger from a very thick and complex client architecture to an outrageously lightweight and flexible architecture based on eventual consistency / roughly-CRDT approach. FB Messenger is doing very fine.
Never rewrite your codebase without a really good reason. Big wins in performance, maintainability, and ease of development may be good reasons, depending on your situation.
With a browser you really can't do that, because you can't force users to update and then you'd have a bunch of semi-working Frankenstein monsters in the wild. A full rewrite and release is the only option.
[0] https://martinfowler.com/bliki/StranglerFigApplication.html
Doing a rewrite is doable and might be suitable, but I guarantee no one there has any idea what they’re doing. They wouldn’t talk of "months" otherwise. 60 million lines is a 5-10 years rewrite, realistically.
People can tolerate injustice to others, but they won't tolerate late checks. If DOGE follows through, I think it will break Republican support in a scale even larger than threatening Canada or sending people to El Salvadorean prison.
We're certainly living in "interesting" times ...
They will absolutely, unflinchingly, uncritically buy "It's the democrats fault" for the reason they can't afford rent.
If these people get angry at Trump, that means trouble for Republicans. And "where's my check?" is just that kind of thing that could make these people really angry.
in this particular case, we've actually already seen what happens - "Xtreme Programming" was birthed from the - failed - attempt to re-write the Chrysler payroll system in Smalltalk in the 1990s: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
edit: and that was run by Kent Beck, not the National Union of Racist CS Undergrads that Musk exclusively hires from
[1] https://www.ssa.gov/myaccount/statement.html
[2] https://www.ssa.gov/manage-benefits/view-benefit-payment-sch...
[3] https://www.ssa.gov/benefits/retirement/planner/applying5.ht...
This is not just about converting COBOL code. This is about converting the JCL (batch processing) jobs to whatever cool real-time processing solution the new architecture is going to have, and about translating the security boundaries from RACF to new security controls. Using AI to 'convert' it might prove difficult, because I don't think we have the datasets to train an AI to do this properly.
Millions of millions, even. "The federal government spent $1.35 trillion on Social Security in fiscal year 2023."[0]
[0] https://usafacts.org/articles/how-much-does-the-us-spend-on-...
What can go wrong and with the inspection service all fired, who will check for backdoors
Again these people need to go, and as others said, save everything you have from SSA on paper and if you can PDFs.
I thought this was wishful thinking / already deboonked?
This part has if you trust Elon as a source. He shared some graphs where there was no spike at 150, and people older than 150. If you trust Elon on this is really up to the reader, but it's a peeve of mine that sources keep reporting the COBOL epoch thing, which was always just a (plausible) theory as fact.
> Again, 150-year-olds are not collecting social security benefits.
This part hasn't. These 150 year olds are simply people whose death hasn't been recorded. They aren't collecting Social Security. In fact social security automatically stops at 115, and the number of Social Security recipients over 100 is within expectations [1]. This if course doesn't not mean there are zero deab people still receiving checks. With any system this size some fraud will exist, the question is how much, and how much does it cost to chase down.
The issue with unrecorded deaths for people over 100 has been known since at least 2015 [2]. In short it hasn't been fixed due to the cost, combined with the risk of incorrectly marking someone dead, which can seriously fuck up your life, not just social security. This whole bruhaha could have been avoided if someone did a 5-minute Google search before Elon/Trump started their theatrics.
[1] https://www.newsnationnow.com/business/your-money/people-ove...
It's consistently pretty damn low, and when problems have been found, they've usually been addressed.
People think these are full of fraud for the same reason they think foreign aid is some insane double-digit percentage of the budget: because Republicans shove messaging at them through dedicated propaganda outlets literally 24/7 complaining about these things, and have done this for decades, and folks don't bother to check.
https://www.youtube.com/watch?v=06H7J0Wjg98&t=233s
a number much lower than the various rates of wage theft that occur/defraud funding of social security by American businesses. Funny which one DOGE is going after first. Seems like Elon should go after businesses fraudulently not funding Social Security as the first priority.
Elon should never be given the benefit of the doubt on anything at this point given how blatantly and frequently he lies. Anything he says should be ignored and assumed to be false without actual evidence.
Right, it's an optimization problem. You fight the fraud to the point that it optimizes loss. If it costs $1 million to stop $10 million of fraud, you do it. If it costs $1 billion to stop $10 million of fraud, you let that fraud happen.
I don't know Social Security's data model, but I wouldn't be surprised if it was still legitimately paying out pensions derived from the accounts of people who'd be 150+ if they were still living.
> “DOGE thinks if they can say they got rid of all the COBOL in months, then their way is the right way, and we all just suck for not breaking shit,” says the SSA technologist
I'm struggling to believe that this is the real motivation. But what is it?
Speculation: they don't know how to backdoor the legacy codebase/platform so they first need to transform it into something they can more easily subvert?
Kind of like "not even wrong".
With the teenagers involved in DOGE under Musk it's just going to be hilarious when they inevitably fail. They just never had the experience to actually go through a complete rewrite of something that's been alive for decades... And never bothered to read "The Mythical Man-Month" because of course they are ninja rockstars 100x developers, and lessons from history and experience don't apply to them.
Really sad that their mess will do very real harm to lots of people who depend on this system working...
I won't be surprised if the "failure" is then twisted as the "success". I see tech projects basking in their success when in reality they just make things harder for everyone. In this specific case, let's see what could go wrong? Someone doesn't get paid their social security — but that's not a bug that's a feature. Govt money saved :).
Instead, we are getting a stupid made-for-TV efficiency, where the leaders refuse to understand technical concepts as braindead simple as a reference date.
Then put it live in alpha
Screw up millions of people
Everyone is a beta-tester with Musk, no matter how dangerous to the product
And didn't just 21 out of 50 "DOGE" employees quit in protest?
https://www.npr.org/2025/02/25/nx-s1-5308095/doge-staff-resi...
Is he going to outsource this to India with data access?
Musk "special hire" status ends June 1st, good luck getting it done by then or maybe this is the excuse he wants to keep going in continued violation of law
> Musk "special hire" status ends June 1st, good luck getting it done by then or maybe this is the excuse he wants to keep going in continued violation of law
Oh and last I checked they were claiming he's only working one day a week, to stretch this out effectively indefinitely. They'll probably get away with it.
the only major 'risk' I can think of about them is talent pipeline.
DOGE wants to rewrite in a few months using Java lol. If it was Ruby maybe like MAYBe.
See "This Is What Happens When Governments Build Software" (Jun 2023):
> There's a lot of frustration about the government's ability to build things in the US. Subways. Bridges. High-speed rail. Electricity transmission. But there's another crucial area where the public sector often struggles, and that is software. We saw it with the infamous rollout of Obamacare. We see it in the UX of the Treasury Direct website. And we saw it in the way state unemployment insurance systems broke during the pandemic. So why is it so hard for the public sector to build and maintain software? On this episode we speak with Jennifer Pahlka, the founder and former executive director of Code for America and author of the new book Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better, as well as Dave Guarino, who recently left the Department of Labor after working on upgrading the unemployment insurance system. Both have a long history of working on public sector software systems and they explain why the problem is so tricky.
* https://www.youtube.com/watch?v=nMtOv6DFn1U
* https://podcasts.apple.com/us/podcast/this-is-what-happens-w...
* https://www.bloomberg.com/news/articles/2023-06-12/why-gover...
One large component is that a lot of business rules and policies have been encoded into the software logic, and (re-)translating that into code in a new(er) language is part of the challenge.
Related, "Why COBOL isn't the problem":
* https://news.ycombinator.com/item?id=41420217
Copy-paste from:
What can an accounting system possibly do? Keep track of people, how much they're eligible for, and when you paid them last. DONE.
> SSA maintains more than 60 million lines of COBOL today, along with millions more lines of other legacy programming languages.
Months?! I hope they mean days. With ChatGPT and AWS, they'll be rolling! All of those millions of lines of code are clearly doing nothing useful.
I think it'll be a very bumpy ride but ultimately the team will succeed.
Besides "liberal sabotage" is a ready made retort for any mishaps along the way.
Do you honestly believe it’s possible to rebuild ANY code base with millions of lines of code, to another language in MONTHS?
It won’t be a ”bumpy road”. It will be a total failure.
This is a reminder to all you Americans to create a Social Security account and print out your statement.
Brilliant !!!!
If so then maybe it's ripe for conversion by LLM.
In particular the XML shows earnings for every year. The PDF shows earnings for several recent years, and then from groups of years before that. I don't know if it is the same groupings for everyone but mine is grouping 1966-1980, 1981-1990, 1991-2000, 2001-2005, then the individual years up to 2024.
I mean, there is a chance that this might work. But I strongly doubt that it would. Given Musk's history of re-writes and deadlines, I suspect that actually its not going to happen.
But on the flip side, if you don't care about complying with the law or caring about users, its probably possible.
Don't get me wrong, the SSA needs some innovation, but innovation, not revolution.
There really isn't.
/s
*had. Doge will make short work of it.