My bull case is not that I particularly like their reforms, but that they demonstrate that substantive rather than incremental changes are possible at all.
Also perhaps that they rip out things that are supposedly doing something useful but sufficiently terrible at it they're not meaningfully helping, such that somebody not-them can later at least attempt to introduce a replacement that does.
Or: The vetocracy problem is very much real and reducing that could, in the medium to long term, be a huge win on net even if the things they do having reduced it in the short term are absolutely not the kind I would like to see either.
> they demonstrate that substantive rather than incremental changes are possible at all.
Substantive-not-incremental change has always been possible, but it's mostly avoided for being a bad idea. Only when we identify an opportunity to make substantive improvement, clear and well understood, should it be used; the default is substantive destruction which is rarely more helpful than harmful.
In software terms, they're looking to rip out entire modules, because they don't understand the business logic that demands those modules. Such substantive change would be pretty idiotic in almost all cases. Refactoring is virtually always the better choice, even if it's hard and takes a long time.
Ripping out a module entirely, only to find it was necessary after all, tends to lead to the same module being rebuilt piecemeal as the missing logic is identified and being as bad or worse than before. In the end, you still need to refactor it if you want it to be good. If you can't afford to refactor, (and you don't have well understood problems,) you're better off not changing anything.
I think that generally refactoring attempts have either failed or simply ended up bolting a bypass on the side that only helps somewhat, and most of the rest of the articles on the same site as the submission we're discussing contain at least one example thereof.
Nonetheless, I largely agree with your metaphor(s) as a projection of how a bunch of things are depressingly likely to go wrong in the short term.
I'd agree with that, because refactoring is hard, especially if you don't intimately understand the domain, and I think "effective government" is much less understood than "high quality software" as a whole, so it's extremely hard to refactor government. Additionally, there are more politics involved in gov't refactoring than code refactoring, so even provably good ideas can get shot down. All the same, I endorse "learn more about the problems and get better at refactoring" over "rip things out" virtually always.
My bull case is not that I particularly like their reforms, but that they demonstrate that substantive rather than incremental changes are possible at all.
Also perhaps that they rip out things that are supposedly doing something useful but sufficiently terrible at it they're not meaningfully helping, such that somebody not-them can later at least attempt to introduce a replacement that does.
Or: The vetocracy problem is very much real and reducing that could, in the medium to long term, be a huge win on net even if the things they do having reduced it in the short term are absolutely not the kind I would like to see either.