> Can’t wait for Musk’s team to finally peel back these layers, realize that the code actually implemented the laws […]
Bloomberg's Odd Lots podcast had an episode on this: the hard part in replacing/updating government system is not the coding part. The hard part is understanding the policies that have been changed and modified over the decades.
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.
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.
> Bloomberg's Odd Lots podcast had an episode on this: the hard part in replacing/updating government system is not the coding part. The hard part is understanding the policies that have been changed and modified over the decades.
That is the hard part in any system, not just government. Especially government, maybe, but not uncharacteristically and certainly not exclusively!
I have read similar things about payroll software. The thing about laws, regulations and payroll is: you do not get to adapt the rules to the software, the software has to implement everything exactly as prescribed. Even that one-off thing from 1977 that still influences a few pensions by a few cents a month.
I work for a company that employs ~5k people. There's an entire IT team just for payroll and it's bigger than Ops. When Elon says he and a handful of devs were going to fix the entirety of the Treasury dept on their own, they are either lying, or have no fucking idea what they're doing. Probably both.
> The thing about laws, regulations and payroll is: you do not get to adapt the rules to the software, the software has to implement everything exactly as prescribed.
You do not get to adapt the rules to the software. The government can look at the state of the rules, say "this rule is obsolete, inefficient or unnecessarily complicated" and enact a different rule.
They rarely do this, which is why having someone go through and make the attempt is potentially valuable.
> That is the hard part in any system, not just government.
Another episode from Odd Lots, "Why Corporate America Still Runs on Ancient Software That Breaks", with Patrick McKenzie (patio11 here at HN):
> Southwest Airlines had a disastrous holiday season, thanks in part to a software bug that left crews out of place and grounded thousands of flights. But Southwest isn't alone in having software in the headlines lately. The New York Stock Exchange recently had a software error that caused weird pricing on stocks and the FAA had its own computer issue that grounded planes earlier this month. So what's the deal with corporate software? Why do these crashes happen? And why does the user experience typically leave something to be desired? On this episode of the podcast we speak with Patrick McKenzie, an expert on engineering and infrastructure, who writes the Bits About Money newsletter and recently left payments company Stripe after six years. We talked about the challenges of keeping any software system alive after years of upgrades and updates, the distribution of tech talent across industries, and whether non-tech companies can close the gap with Silicon Valley.
Bloomberg's Odd Lots podcast had an episode on this: the hard part in replacing/updating government system is not the coding part. The hard part is understanding the policies that have been changed and modified over the decades.
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
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