It wasn't a big project, I was the sole coder. What had been sold in was basically a Drupal install with some customization. I made sure they wrote a decent specification before I accepted the job.
I delivered on time and we had the first test with the client. Everything went very well, and the client seemed happy.
On the client side, the project was then moved from the project group to those who'd actually be using it. And then came the question from the new manager:
Mgr: "This looks nice, but what about all the other sites?"
Us: "Other sites? The contract was only for one site."
Mgr: "Well, the whole point here was to have 17 sites with site-specific content written by site-specific users, managed centrally with a unified look as if it was one single site."
Us: "Err... that's not what the specification we agreed on says."
Mgr: "Well, as it stands this is useless to us."
And so the simple three day job turned into many weeks.
Had I not insisted on such detailed specs though, it would likely have been a lot harder to get them to pay up.
So yeah, worked out fine for me, but taught me a valuable lesson.
It facinates me that no one ever stopped to wonder if was actually possible to implement all that.
It failed horribly, costing billion of DKK in implementation cost and even more in taxes that couldn’t be collected.
Taken together, the complexity of the law just accumulates. Tax law in Denmark being a particularly gross example.
One major issue, at least with Danish law makers, is that they want to target special groups, but that would be discriminating, so instead they attempt to target the behaviour of those group. This of cause will affect a number of people who where not in the original target group, so they add on exceptions and and details to narrow down the law. Also there never seems to be any clean up in the laws.
If your laws/rule exploded from a few hundred pages to 30.000 pages, you should really revisit that thoughts behind that law.
There's a lot I love about life in Denmark. This is just to say that no place is perfect and DK also has stuff that all Danes should be rightly embarrassed about.
One might wonder what would happen do Danes abroad not respecting the local customs in certain conservative countries.
Isn't this basically a given? I find it hard to imagine that any organization could come up with good, complete requirements before they've had any software written.
Governments by their nature tend to approach everything from a legal perspective.
This then means the requirements of these big IT project end up being a mass of legal documents which try to describe what is being delivered by whom.
Then when the whole thing falls apart it ends up in the courts and the court then decides who promised what based on those original contract documents.
The relative was asked about his CS job, and at some point details were being discussed. The relative said something like “we have made what was asked for but because we have run out of time, that’s what the customer is getting. We know what they actually want and need, but that’s not in the contract”.
The person we were talking to was the customer.
Something government contractors learn to be good at is following a spec. These lawsuits often end-up costing the taxpayer a fortune for the government to be told that everything was delivered according to their spec.
The consulting company will then recoup it's losses from the lawsuit using their hourly billing clause where it stipulates that they can modify the software for X$/hour.
It’s also why Gene Kim & co wrote “The Phoenix Project” [1].
Everyone involved in software-building, non-tech industry should read it.
In the end it’s just lean turned agile software dev. Reduce waste.
[1] https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
Take a look at how kmalloc_obj is going in DragonFly BSD.
Government IT challenges three technical team leads to get to solution like kmalloc_obj. Performance pays for 1st prize and the rest get less money. Cut the time horizon from start to finish for the piece work to 18-months. Spread the risk of total failure to zero.
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.
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.
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.
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.
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.
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.
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.
You mean the guaranteed-to-fail-but-spreads-blame method that I mentioned is common and closely related to your proposed method which shares those traits? Because that's neither “my way” nor something I recommend as an alternative.
> The problem with your method is that two separate companies have deliverables that must be correct,
No, only the final delivery company’s one must be correct. The preceding one influences the likelihood of that, of course, just like the extra domain-expert contractor brought in to validate the requirements in your proposal. (Who, if the agency for which work is being done is bringing them is as a requirement “validation” expert because it assessed that it can't do that, is effectively defining the actual requirements, even if nominally they are just validating the other firms work on behalf of the customer.
> It's fundamentally impossible (absolutely, 100%) to write specs for a complex product before the product work begins.
Yes, you seem to understand a key part of the basic problem, but then describe a rearranging-deck-chairs-on-the-Titanic solution that does nothing to address it.
> And my way removes the back-and-forth which is a huge source of errors.
No, it just changed to nominal role (but not really the functional role) of one of the three (customer, requirements crafter/validator, developer) parties to the back and forth.
My way is to recognize that if you are going to build and operate a complex IT-dependent business function, a prerequisite step to success is to own the IT capacity to govern the necessary system components, including their incremental development and adaptation to evolving business needs. And closely related to that is arrange the work into increments that (among other criteria) can be plausibly specced in advance but also where the setback isn't intolerable when an increment’s main output is information about where your understanding going into it was wrong.
Right, just become an IT organization. That's the simple answer nobody talks about.
This is a non-answer because even most companies that want to can't do this, and as a taxpayer I don't want my government developing IT excellency, I want bureaucrats doing their core task not writing specs. (When they leave the agency they could go to the business process consultancy I mention, where they monitor and advise the developers in tax questions and departmental process issues.)
Their IT budgets are often ginormous with very little to show for it. Consulting havens. Slow, if at all, moving project organizations.
It’s about size, budget models and competences.
Time for another rant:
Note that Sweden have implemented “new public management” NPM which basically pushes government agencies to govern like the ever oh so successful free market companies.
This has had many really bad side effects since the 90s and it’s right up the neoliberal alley.
In my book it’s just silly and something only professional politicians together with consultants can cook. But it’s a different story, really.
My observation of corporate organisations attempting to guide software development is just as bad.
I’m a proponent of doing these things in-house, however that path is far from straightforward and has masses of pitfalls too.
The Phoenix payroll system comes to mind, the Canadian government tried to shift the blame to IBM, but have their hands tied since IBM delivered exactly what was in the contract. It's just that what the government decided to put in the contract has little to do with how they really do payroll.