> That's why all this stuff is backed up to an iron mountain.
When one of your threat vectors is a massive ball of nuclear fire right on top of the federal government in DC, your offsite backup policy is going to be absurd overkill by the standards of any other organization on this planet. That doesn't mean it's flawed.
> ...many of the people in charge don't even know how to use a website. Now for the first time, tech industry people have the opportunity to help run these computer systems, and you're afraid they're the ones who'll be incompetent and accidentally break everything?
Are you honestly suggesting that the people who built these systems, maintained them, and updated them to reflect often significant changes in rules and regulations over the course of decades somehow don't know how those systems work? If they were so damned clueless, those COBOL systems would have sputtered out and died decades ago. The fact that they've continued to run for all this time is practically prima facie evidence that the system works just fine by industry standards for that kind of legacy code.
No doubt there's plenty of stuff buried in the codebase that bugs the hell out of the developers working on it, but you get that with any complex legacy code. It's the nature of the beast. Do you think there's nothing in Google's monorepo that some of their engineers don't quite like but doesn't rise to a big enough issue to warrant refactoring right now? Any other FAANG company? Or large tech company in general?
You're writing as though a bunch of junior developers--and that describes pretty much all of the publicly known DOGE employees so far--are wizards who can just waltz right in and magic up a better solution just because they're from the "tech industry."
Setting aside the unlikely chances that those juniors--no matter how skilled or talented--have any experience with COBOL, mainframes, or even just decades-old legacy code, is anyone going to suggest that something like the federal government's payment system isn't defined by an immense amount of complex business logic so as to comply with legislative requirements? It's not something you just start playing around with.
I can't think of any tech company that would take a junior developer, toss them overboard in the middle of the freezing Atlantic, grant them sudo access, and tell them to do whatever the hell they want with critical systems before they drown and--somehow--take the ship with them. Worse yet, those juniors were chosen for ideology fervor and/or purity, so what happens when the normal review processes and experienced senior developers are pushed aside because they're in the way and part of the "deep state conspiracy" that doesn't want them to "[fix] the government" as you put it?
Not only is that a recipe for disaster for the company itself, it's a damned good way to take an otherwise talented junior developer and permanently ruin them. Instead of mentoring them so they can work well as part of a team, you're basically creating a toxic working environment that's going to turn them all feral. By the time they crawl out the other side and the public hears all about what they've been up to, what company is going to be stupid enough to a developer with "DOGE" on their resume? Beyond that, you're conflating a whole bunch of different issues here with federal software contracts and IT, while putting the tech industry on a really peculiar pedestal.
Besides, if the goal is to discover waste/fraud/abuse, the obvious answer is to hire a bunch of forensic accountants and let them dig into everything. Those are the people who actually find that kind of stuff, and they're incredibly skilled at their job. If it's there, given the time, they'll find it. But it's a slow-going process, so we instead see a bunch of engineers focusing on random transactions so they can ask themselves (1) "do I like that one?" and (2) "do I think it's legitimate?" because it's faster.
That's not exactly how you fix anything, least of all a country.