[Rule35]

Right. But the client should never come up with the detailed spec. If they know what needs to be done it'd literally be faster for them to code it themselves.

They should never produce more than a page or two of specs, outside of the central task itself, because most everything will change when under production anyways. A project like this is big enough that apps became a thing, and fundamentally changed twice, in the lead-up to the actual work.

And all the little things they could control are just bikeshedding, best done by an impartial designer or by A/B tests.

[WesolyKubeczek]

Yes, but your way would likely strip a friendly consultancy off a contract for a couple million of your favorite currency to produce said specifications.

[908B64B197]

> If they know what needs to be done it'd literally be faster for them to code it themselves.

They would need to hire software engineers and, quite frankly, most municipal governments aren't capable of adequately compensating these positions.

[dragonwriter]

> They would need to hire software engineers and, quite frankly, most municipal governments aren't capable of adequately compensating these positions.

Of course they are, because they already are compensating them plus contract management overhead on both sides of the contracting arrangements (which are usually made even greater because they have different contractors for different phases of an effort), plus contractor profits.

Aside from simple corrupt motives (both by responsible managers involved in deals directly and higher-level politicians who favor inefficiency of kicking things off to industry because it buys support from the beneficiaries), this is done because it spreads the blame in the event of failure, which is seen by many involved as more important than maximizing likelihood of success or cost efficiency.

But citizens (well, at least those not corruptly benefitting) shouldn't tolerate that.

[908B64B197]

> Of course they are, because they already are compensating them plus contract management overhead on both sides of the contracting arrangements (which are usually made even greater because they have different contractors for different phases of an effort), plus contractor profits.

They have the budget for it, that's sure. But more often than not the municipal workforce is heavily unionized and has paygrades that are below market rates.

[dragonwriter]

> They have the budget for it, that's sure. But more often than not the municipal workforce is heavily unionized and has paygrades that are below market rates.

That (the below market rates) is part of the setup to promote outsourcing. A heavily unionized workforce doesn't make it harder to for an organization to increase tech role pay to market rates if it wants to, it makes it fight harder to avoid to doing so.

[Rule35]

Right, so they also don't have the capability of writing the spec. Knowing that they should just hand it all off.

[908B64B197]

That would be even worse! Can you imagine the headlines where it's a private company that tells the government what they need to buy AND sells it? Horrible conflict of interest.

The best solution would be for government IT to simply be competitive with the private sector for talent acquisition. That would probably mean that most senior software engineers will end-up being above the mayor's paygrade however.

[Rule35]

Can you imagine the scandal if you fully specified a product and they built it and it wasn't even fit for task. Your contractor says "They never said it had to fly, they just sent us 5999 pages of specs about the logo, the color of the seat, the tray-table latch mechanism, etc." You'd look even dumber because you proved you don't understand your own business.

No organization should expand outside its desired core competency. Specialization is for organizations. If you want competency you hire it as a consultant. If you need to check that consultant, hire another.

Hire one company to write the spec and the product. Hire two others, small firms, one in the problem space (tax, airlines, etc) to check the business requirements and one in the software space to make sure spec/dev/test processes are adequate.

> Can you imagine the headlines

Yes, 100% lies written by a bitter communist. Modern corporate media in a nutshell. But the government already took the brunt of that for screwing up earlier. The screwup you mention would be no worse. Partly because the news is hyperbolic and nobody believes it these days - every problem reported is the worst ever.

[dragonwriter]

> Hire one company to write the spec and the product. Hire two others, small firms, one in the problem space (tax, airlines, etc) to check the business requirements and one in the software space to make sure spec/dev/test processes are adequate.

Your projects will never succeed this way, but you’ll have plenty of people to blame for the failures.

Which is why it's already common for government IT projects to use a close variant of this approach, but usually separating out requirement writing to a firm notionally expert at doing that in the problem space instead of having it checked by sich a firm.

[Rule35]

> Your projects will never succeed this way, but you’ll have plenty of people to blame for the failures.

We're discussing how it failed your way, so I'm not so sure you're presenting a better alternative.

The problem with your method is that two separate companies have deliverables that must be correct, whereas with mine only one does. And my way removes the back-and-forth which is a huge source of errors.

It's fundamentally impossible (absolutely, 100%) to write specs for a complex product before the product work begins.

So you can make it work your way, with a separate firm writing the specs, but you need to couple them with the dev firm and give up on the fantasy of up-front specs.

But that comes with its own problems and increased cost so imho you're better-off just letting one firm do it.