Rebuilding the Social Security Administration’s Codebase
The project is being organized by Elon Musk lieutenant Steve Davis, multiple sources who were not given permission to talk to the media tell WIRED, and aims to migrate all SSA systems off COBOL, one of the first common business-oriented programming languages, and onto a more modern replacement like Java within a scheduled tight timeframe of a few months.
[…]
This proposed migration isn’t the first time SSA has tried to move away from COBOL: In 2017, SSA announced a plan to receive hundreds of millions in funding to replace its core systems. The agency predicted that it would take around five years to modernize these systems. Because of the coronavirus pandemic in 2020, the agency pivoted away from this work to focus on more public-facing projects.
[…]
As recently as 2016, SSA’s infrastructure contained more than 60 million lines of code written in COBOL, with millions more written in other legacy coding languages, the agency’s Office of the Inspector General found. In fact, SSA’s core programmatic systems and architecture haven’t been “substantially” updated since the 1980s when the agency developed its own database system called MADAM, or the Master Data Access Method, which was written in COBOL and Assembler, according to SSA’s 2017 modernization plan.
When the original X.com merged with PayPal, Musk wanted to rewrite the code and switch everything from Unix to Windows. Part of the thinking, if I recall, was that it would be easier to hire Windows developers. The original PayPal engineering team rejected this and maneuvered to have him replaced as CEO.
It probably is a good idea to modernize old government systems and get them off COBOL, but Musk is not known for the careful approach that doing this properly would require. Still, it’s interesting to think about how this should be done. I wonder if they could run the new system in a sandbox for a year, feeding it all the same inputs, and see whether it generates the same outputs.
Note that the existing system is tested but not problem-free. It seems to be pretty reliable about dispensing payments, but there have been multiple multi-month periods where I was not able to log into my account or I could log in but it wasn’t functional.
Previously:
6 Comments RSS · Twitter · Mastodon
The web interface is very new relative to the functional part, which is old and well tested. The DoD also dispenses trillions of dollars from its COBOL-based system, which dates to the 60s. Both the SSA and DoD have modernized their COBOL over time. They use modern programming environments to interact with tested code that's running on relatively modern computers.
The assumption to use a certain technology just because it's easier to find developers for it is simply stupid. A company doesn't hire programmers for their knowledge in a certain technology, they are hired to work on their product. And there is magnitudes more in-depth knowledge required for that product's internals than that little bits that a certain technology would bring to the table. Learning the language and the technology is the easy part. Learning all the corners and pitfalls of the actual app, that's where things get interesting and that's only learned over time. So hire early, especially while there're seniors around and then let them maintain the app until they retire.
"I wonder if they could run the new system in a sandbox for a year, feeding it all the same inputs, and see whether it generates the same outputs."
They won't. They'll shut down the old system and scrap all the old equipment before the new one is even working right.
5 years in 2017 is how long with AI doing conversion now?
Agreed on testing, but given the productivity boom AI is going to be bringing previous estimates may not be relevant and perhaps it is finally the time to rip the bandaid
@Karsten - I agree completely. But this line of thinking is a good part of why so many engineering orgs have standardized on ReactJS and NextJS.
>It probably is a good idea to modernize old government systems and get them off COBOL
Many banks and insurance companies still have COBOL systems running some of their most trustworthy code, with no plans to replace them. COBOL is still in active development; it's specifically designed for these types of applications and is stable and performant enough. It's also not exactly difficult to learn. If you can learn C or Rust, you can pick up COBOL.
Would you choose COBOL for a new system? No. But if you want to replace some of the most well-tested, critical systems, you must carefully consider whether the risks outweigh the advantages.
>5 years in 2017 is how long with AI doing conversion now?
It's still five years, but with many more bugs and nobody who understands the code base.
