[BREAKING UPDATE] No, Musk’s Teenage Tech Bros Can’t Rewrite the Federal Code Base in a Week
Tonight's Social Security Data Breach forces me to update this article.
Tonight, we learned from multiple news sources that the Coup d’Etat provocateurs of Elon Musk and his team have forced the resignation of Michelle King, the acting commissioner of the Social Security Administration. She resigned when the so-called DOGE team demanded access to the data affecting every working American.
Presumably, Musk, whose access to these files is an illegal act, will use his claim that 150-year-old Americans are receiving social security as justification for this stage of his coup.
If he knew anything about COBOL, which is likely still a big part of what powers the Social Security Administration’s computer services, he’d know that the “150-year-old American” is the result of a COBOL peculiarity and he could resume his practice of telling four-year-old Lil X that Trump is not the real president, and teach the kid a few more F-bombs instead of hacking social security data.
My original story is no longer relevant. I originally said we had some time for various Trump opponents to take action to expel Musk from government premises.
Time’s up.
Here is my emergency update to the article. Strikethroughs intended.
Many people are worried that Elon Musk is about to rewrite the code base of the United States government.
They’re worried about this because the mainstream media is saying that Musk’s tech bros, apparently, according to Wired Magazine,1 led by 25-year-old Marko Elez,2 are planning to “migrate” the systems as early as this Saturday.
I’m as concerned as everyone about Musk’s coup d’etat and the rather high long-term likelihood of a data breach as a result of his unprecedented access.
But I want us all to also understand that there is only so much one guy, or even 5 or so, can do in one week. We have time to fix this.
I spent many years in the software coding biz, including several years at Elon Musk’s old haunt, PayPal.
He left long before I arrived, so I wasn’t blessed with the opportunity to run into him in the breakroom so that I could spill hot coffee on his head while chatting with him about who was most responsible for losing South Africa’s apartheid system — the English or the Afrikaners. This is obviously a sore point for the ketamine-soaked lad, but I digress.
Despite his former presence there, PayPal was one of my favorite stops during my software career. He did not leave his lecherous skin cells behind to enough of a degree to affect long-term damage to the company's psyche.
The people who worked there were incredibly pleasant, even when the deadlines were not. There was a bit of a tech bro feel to the rooms,3 but I didn’t personally notice any misogynist treatment toward women, although, in fairness, there weren’t many females around to be mean to.
Musk left the company after an internal battle over server software. Musk wanted to switch to Microsoft Windows, but co-founder Max Levchin, who wrote the underlying code base for what we in the web development business call the transactional layer, pushed back.
Wait! Don’t go! Don’t worry, I’m not going to get all technical here. I want to explain why the federal government’s software systems can’t be rewritten overnight like the press wants you to think they can.
Can they be rewritten? Of course, but it would take a humongous amount of time.
Let me explain.
Remember my tiny history lesson about Musk and PayPal? The PayPal codebase, compared to the various pieces of the federal government, is diminutive. Nevertheless, migrating its servers, which send the data you need to make a payment, from Linux to Windows would have been a major undertaking.
When I started working there, the company was in the final stages of migrating from Levchin’s transactional layer, which he humbly called MaxCode. It was a long time ago, but if I remember right, it took about a year to completely migrate the transactional layer toward more traditional computer languages (we used more than one).
The only people in the entire world who knew how to write MaxCode were PayPal employees. This meant that, no matter how good you were writing software, there was some ramp-up and training involved. Very silly. So the migration was necessary.
But the migration took time. Not only development time, but, most importantly, significant testing time.
You don’t just flip a switch and get a magical “hello, migration complete” response from your computer systems. Integrating major changes into the code base of large enterprises takes many weeks, often months, even if you have a hundred software engineers involved.
The federal IT system is so much larger and more complex than PayPal’s that it almost defies explanation. It uses Oracle, Salesforce , SAP, Pega, and dozens of other software and software-based solutions across a multitude of agencies.
For years, the feds have wrestled with establishing a more cohesive integration across its various agencies. They’ve accomplished some of that, especially with customer-facing services like Social Security, which, despite such integration, still uses three different authentication (login) systems to grant you access.
But it’s still a complex, not at all interdependent system in many areas.4
The Social Security Adminstration doesn’t have three separate authentication systems because they’re trying to be silly. It’s because it has taken them years to migrate into a standardized authentication process. The multiple dependencies on the Social Security login system are such that they have had to retain legacy systems until further notice.
As I said, migrations take a long time.
To help you understand why the tech kiddies can’t do much damage at first, I’m going to try to briefly describe how a typical customer-facing software system works. Don’t worry, I think I can do this in a way that won’t make you non-techies want to subject me to a loop of Trump speeches while I’m tied to a chair.
I won’t even include diagrams. Let’s skip the diagrams!
A typical system works like this:
There are generally three layers.
One: The database Layer.
This is where all the information is stored: Your name, your social security number, your date of birth, etc. This is very sensitive information, as you can imagine, so there’s a name for it: personal identifiable information (PII).
When PII isn’t protected well, bad things happen. And have happened. Yahoo exposed three billion accounts in 2013-14, revealing things like date of birth and addresses. There have been many more, including, lately, several medical records firms that have exposed social security numbers.
It even happened to me. Somebody tried to buy a car with my social security number in Minnesota shortly after I received a letter about a medical data breach. I’ve never lived in Minnesota. I found out about it because the company financing the car was able to track down my phone number and call me.
So, data breaches like this are a big deal.
Because of that, the data is usually kept in the software equivalent of a locked safe watched by surly people bearing weapons.
Those folks are called database administrators (as shown in the YouTube video), and they don’t take kindly to strangers knocking on their door and asking for entry. I doubt Musk’s tech bro kiddies have encountered these people yet. Database administrators are very protective of their domain. Even more so when PII data is involved. You’re not getting in without a fight. That alone could take those kids a week, assuming they even survive asking the question.
Databases, of course, hold a bunch of other information, typically in a different database than the personal stuff. How much money the government owes you, for example, will be held in a different database, probably administered by a different group of people. Also very surly.
I’ve never worked with government software, but it’s highly unlikely they use one kind of database software. Some might use Oracle, another SQLServer, but there are dozens of other kinds, and, knowing how the government seems to operate, it probably uses a mixture of everything on the market.5
I know this because whenever I’ve perused federal job opportunities, I’ve seen a wide range of different software requirements. Plus, when I was younger, I used to talk to people.
So that’s one layer. The database layer.
Two: The transactional layer
Another layer is the transactional layer. This is the layer of software that processes the data you send or request. It either retrieves information from a database or delivers your requested change to the database. The government uses all kinds of different software languages to accomplish this. There is not one specific federal standard.
Some of this software is still very old. Several initiatives have taken place to standardize the process somewhat, but it is still a mélange. A potpourri. Some software people I’ve talked to use less charitable words, such as clusterf*ck.
During the last twenty years or so, various software protocols and standard data structures, like XML (a markup language similar to HTML but used strictly to pass data around) have emerged. But it’s still a hassle to integrate two systems that use different languages. When you add the fact that many government agencies use pre-packaged software solutions, the complexities of inter-agency communication grow accordingly.
But the government doesn’t consist of two, three, or four different systems. There are hundreds.
There isn’t a small cadre of tech bros in the world that can migrate the large transactional systems of even one agency, much less several, overnight. Or in a week. Even small changes in government software often require extensive testing to see how the changes integrate with other agencies.
Every computer language has its own syntax and personality quirks that take time to master to avoid bugs. It doesn’t matter that some of these kids are, literally, rocket scientists. They can’t master a new language in a week.6 They can’t make substantial changes in a week even if they’re familiar with the computer languages. Hell, they can’t even test it all in a week.
Every change in a code base requires something called “regression testing,” which tests whether or not your code broke something else that was previously working. Regression testing, in my experience, takes two weeks on a large system, and that’s if you have a lot of people involved.
You might scoff and say, “These punks won’t test,” but, well, if their experience is at places like SpaceX and Tesla, I’d argue that such experience is an effective counterargument.
So, that’s another layer. The transactional layer.
Three: The presentation layer
This is the layer that tells how a web page to render or, more generally, how a software app like Word looks when you work with it. You run into the presentation layer every time you mess around with a phone app like DuoLingo. If you think it looks cute, it’s because some good user interface designers worked with the coders to make it so.7
The presentation layer is probably the most fun aspect of the whole process, but the least important to this discussion, so I’ll just leave it at that for now. If you want to learn more about it, and because I’m old and would rather refer to someone else old, too, Google “Jacob Nielsen” and call it a day.
The Musk kiddies could probably crank out a new web look in a couple of weeks, if only because the damage caused is mostly one of annoyance. A missing button here, some missing data there. But mistakes won’t destroy the system as a whole. It’s a completely different layer. The “make it pretty” layer.
The sum of the parts
For years, software engineers have derided the federal software system because, essentially, there isn’t one. It’s always been a collection of hundreds of disparate systems that work poorly together.
It’s safe to say that Elon Musk, whose name I never saw in the PayPal code repository, had his teeny boppers take a look at some of the federal software and one of them said, “Boss! I can fix this in a week!”
But I doubt it. These guys worked on rocket ship software. They were probably more realistic than that. They probably slapped their forehead when they took their first peek into one of the software layers at one agency and asked out loud, “How do these people work with this cruft?”
But they’re not changing it in a year, much less a week.
If you want to worry about Musk and his tech bros sticking their noses around the government’s software systems, devote your concerns to Palantir, Peter Thiel’s software that knows more about you than you do, and has reached the point that it probably counts the number of stools you generate from your morning poop.
But that’s another article.
Stay safe, and remember to smile.
Thanks for reading!
Take to the streets, people. We can’t count on Democratic congress critters to help us.
Notes
Elliott, Vittoria. 2025. “The Young, Inexperienced Engineers Aiding Elon Musk’s Government Takeover.” WIRED. February 2, 2025. https://www.wired.com/story/elon-musk-government-young-engineers/.
For you software engineers out there, he appears to be mostly a Python and C++ guy: https://github.com/markoelez. Of note: he removed his photo from the Github page. If he’s receiving death threats and the sort, that’s as bad, or worse, than him having access to government systems. Don’t hassle him for not being adult enough to know better. This is all on Elon, not his kiddy friends.
I’ll never forget the guy who brought tequila to our morning sprint standups.
If Musk was an actual humanitarian, he’d help the Veterans Administration, which is famous for its technical hiccups.
Just a few possibilities: SQLServer, by Microsoft, Oracle, by Oracle Systems, MySql, an open source database, PostgreSQL, another open source database
Some reports have filtered in that they’re using, or are proposing to use, AI to help, but AI coding applications typically only help you bootstrap the initial code, and, if not tested rigorously or if it’s not used by highly skilled coders, can cause more problems than it solves.
Sometimes, these are the same people.
Why are people with high levels of access and responsibility in government not expected to be random drug tested?