The money that the fairly small team are spending is a drop in the ocean compared to many government funded projects. If you want to get angry about misspent public funds, I can think of countless other areas that are orders of magnitude worse. The reality is that a small team of people directly employed by the government working fairly effectively can build and discard their stack as many times as they want and still be significantly cheaper than getting a big company to do it.
It's my job to look at dysfunctional teams both from a technology and a process perspective. I've seen teams like this many times before. They are expensive, inefficient and the return is considerably lower than the investment has promised.
Just because the historic approaches are worse doesn't exclude these guys from scrutiny. They'll quite happily piss £40k of dev cost up the wall while other departments are arguing over £200 ultrasounds for cancer patients. Scrutiny must be universal and unforgiving.
I've not been watching them closely, but they are delivering, which seems an extremely strong indication they're not dysfunctional at all.
Every now and then I end up on a gov site they've redone and it's immediately obvious they've had at it because it's easy to use, responsive, etc.
You're sounding like one of those pointy haired bosses that don't understand that good developers play to succeed, and it doesn't always pay off. But if you stop them you end up with crap because the good people leave.
Sounds more like a pointy haired boss to me.
It's called agile development, and it lets them respond quickly and efficiently to changes in requirements / mission.
See also: Facebook, Twitter, most other tech companies.
That notwithstanding, I'd also be very interested to know how agile is a panacea to fast-changing requirements, especially as opposed to techniques such as designing for change (at the architectural level, so not just the implementation level, i.e. loose coupling, encapsulation and abstraction interfaces).
* Experimentation doesn't make it into production twice unless you're doing something wrong.
* There are proven solutions off the shelf both open source and commercial.
* They should be value driven rather than innovation driven. We aren't paying them to be a research agency.
* There is an ongoing maintenance cost and in-house only knowledge when you do an NIH job of something. That is not efficient.