> where we identify public servants with strong technical aptitude across government, bring them into dedicated product teams

> The team’s approach was straightforward. Build working software fast. Put it in front of real users early. Collect feedback. Fix things quickly. Release updates every two weeks.

> That’s a 95% cost reduction. Both systems instead of one. Delivered faster. With 643 users already on the platform

This is a proven solution. These parts, the non-AI management ones, are proven to work in all sorts of places. Gov.uk is another example.

However, there's one massive problem with this: it doesn't involve the free market and it doesn't make any money for corporations to feed back to politicians in campaign donation kickbacks. It even involves respecting civil servants - maybe even paying them market wages! These parts are so heretical that most governments would choose the solution that 10X more expensive and also doesn't work, every single time.

You are missing the larger problem: it isn't a fixed capital cost you can put in the budget.

Modern accounting (for some good reasons) counts different costs in different buckets. If you invest in a system, the cost should be spread out over all the years the system is in use. However if you investing long term we want to be sure it is worth the investment - there is a point where something is not worth the cost. For things that are only for this year we can easially understand if the cost was worth it, but if we need to spread it out over many years it is much harder. If we can set a cost today we can have a debate on if it is worth the investment.

However designing something is not an fixed cost process. I cannot say if it will take me 1 week or another year to get the current bug I'm working on fixed, but if it takes more than a month my boss will say it isn't worth the cost of fixing it. (and then we get to sunk costs: what if I put in 1 month and am only 1 day from the fix, should I quit now?)

When you put a design contract out for bids they have to go big. They have to deliver for $54M even if things are harder. When someone says the real cost is likely to be $100M they really mean that once you have the $54M version you will realize what you wanted wasn't what you needed, and there is $46M in extras to turn what you specified into what you really need.

more general, it's related to the ongoing struggle between private vs state owned utilities. it is not clear from the get-go which approach is better. it most often depends on the quality of the people involved.

The original idea of doing it privately was that free market will compete for best solution at cheapest price but many, many, many projects later it ends up not being cheapest nor best, just ones that can navigate the politics and red tape best. And that before any kind of corruption gets involved.

It also gets very silly, like one public one that company I work won was literally just iterating the company that currently hosted their infra infrastructure, so the previous company automatically checks all the boxes and any new one have to fit that, and it went to silly degrees like describing clockspeed of CPUs that have to run it. We just gave them older servers that happened to have higher clocking CPUs so the requirement backfired badly on them.

And that is not even neccesarily malice on their party, they just didn't wanted to go thru PITA of migrating everywhere just because some pencil pusher required looking for vendors every few years "in case it will be cheaper".

[dead]