4 ms·
Bloomberg's Odd Lots podcast had an episode last year, "This Is What Happens When Governments Build Software": * https://www.youtube.com/watch?v=nMtOv6DFn1U ht
by throw0101b 2y ago
Bloomberg's Odd Lots podcast had an episode last year, "This Is What Happens When Governments Build Software":
* https://www.youtube.com/watch?v=nMtOv6DFn1U https://www.youtube.com/watch?v=nMtOv6DFn1U
One reason COBOL systems have been around for so long is because they encoded business rules that need to be understood if you want to try to transfer them to a new system. From the podcast (~16m):
> Like when we're working in unemployment insurance, again during the pandemic, my colleague was talking with the claims processors week over week and we're trying to dissect it and figure out what's going wrong and clear this backlog and one of these guys keeps saying, “Well, I'm not quite sure about that answer. I'm the new guy. I'm the new guy.” And she finally says, “How long have you been here?” And he says, “I've been here 17 years. The guys who really know how this works have been here 25 years or more.”
> So think about. You know, going from doing some simple cool, you know, tech app, you know, easy consumer app to trying to build or fix or improve upon a system that is so complex that it takes 25 years to learn how to process a claim.
> That's sort of, I think, what needs to be on the table as part of this agenda is not just “can the tech be better?” But can we go back and simplify the accumulated like 90 years of policy and process that's making that so hard to make?
Also an observation on how decisions are sometimes made:
> And I think that there's a deep seated culture in government where the policy people are the important people. They do the important stuff and technology, digital is just part of implementation, which is not just the bottom of a software development waterfall. It's the bottom of a big rigid hierarchy in which information and power and insights only flows from the top to the bottom.
> And so it's problematic in part because the people who are doing the tech are really just sort of downstream of everything else and the power and ability and willingness to step up and say “Hey, we probably shouldn't do those 6,700 requirements, we should probably focus on these 200, get that out the door and then, you know, add edge cases as as later.” There's no permission really to say that.
- shadowgovt 2y ago> ...add edge cases as as later.” There's no permission really to say that. I think there would be some value to closing that feedback loop to give legislators the signal "You know, what you're considering is actually pretty fuzzy conceptually... We're discovering while considering how to code it up that you probably don't actually have good, clear definitions for all the terms in this bill." But the biggest thing to remember about government IT is the clientele, which changes the approach from commercial / industry software. Google can optimize for the common case. Google can cut the edge cases. Google can change APIs on a whim. Google's users choose to be Google's users and can go elsewhere if they don't like it. Government citizens don't have that choice. And in general, people don't lose access to their food if Google effs up. Or go without their legally-deserved unemployment pay. Or go to jail because their taxes were mis-calculated. In the government space, the "edge cases" are human beings, alike in dignity. The rules and policies end up complicated because human beings are complicated. And yeah, it ends up being some messy software. Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset.
- Muromec 2y ago>Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset. That's all very true, but nobody ever codifies that. When the data doesn't fit the constrains of the form that aims to handle a reasonable generalilized case, you simply get a phone call from a human in the loop. That human has a supervisor and you can also go to a court when they write your name with E instead of É and try to bullshit you about some kind of ASCIEBCDIC nonsense like it's real. In the end you have one dataset which tells who is a child of who, another telling who has custody rights and a third one making sense of amounts and recipients of childcase subsidies. Maintained by different departments and eventually consistent or maybe not.
- spongebobstoes 2y agoMy interpretation is a little different. We agree that humans are affected by the edge cases, although I believe that's also true at very large companies like Google or Meta. I don't think it's about avoiding programming 6700 edge cases, but more so that when you have an excessive number of cases, it's likely an indication that something is being missed. that could be due to a bug in software or due to unclear definitions in the legislation. in those cases, rather than attempting to program it exactly, it might be better to bring a human into the loop. and to me, that could be the point of having a tighter feedback loop. because otherwise the developers will just do their best, which will be buggy or incomplete. because they can't not do their job.
- Muromec 2y ago> There's no permission really to say that. There is not permission to say that because your requirements are often set in a black letter law and you didn't buy a right kind of suite to be present where they were decided for the last 40 years.