[jaabe]

What high quality software?

I work in the public sector in Denmark, we operate 300-500 systems from private suppliers and none of them work, none of them are particularly cheap either.

Our medical software on life supporting machinery is about the only software that actually always does what it’s supposed to, but it goes decades without changes. Everything else is a broken mess, regardless of what principles of development the companies adhere to.

I think the only software that we operate, which is both high quality, stable, secure and capable of adding/removing features when we ask is our dental software, and that’s actually some of the cheapest software that we buy. It’s not made by a tech/development-house though, it’s made by a couple of former dentists who do it as a side product on their main business which is selling dentist equipment.

So maybe the real issue lies with the development houses? But our experiences are obviously anecdotal so it’s hard to say.

[dTal]

Obviously anecdote != data, and you don't say what the software does. But your story would seem to imply that domain knowledge is more important that software development knowledge. There's a certain logic to it - someone who deeply intuits what the software is trying to model will naturally gravitate towards the correct abstractions, even if they're ugly and ad-hoc; while a professional software developer with no domain experience with happily build a shiny tower of abstraction that doesn't fit the problem domain, and chaos will ensue.

There's a reason we emphasize nailing down requirements before committing code. But what if it goes a level deeper than that? Perhaps what we actually need to do is understand the mindset that is generating those requirements. Perhaps, for some types of software, that's equivalent to being a domain expert.

[TeMPOraL]

> But your story would seem to imply that domain knowledge is more important that software development knowledge.

I think the story suggests alternative explanation: that the product is a side project for the people that make it, probably even considered as a marketing expense. So they don't have the usual software-house incentive to fleece the government while delivering worst possible product. Wouldn't be surprised to discover that these dentists don't consider it a high-pressure project, so they actually take time to do it right and be proud of their work.

[chvid]

The real issue is that you pay them to deliver bad software.

I know it sounds like a weird thing to say. But had you as a customer demanded and were willing to pay for something different, you would get that.

Think about how the public sector buys a software development project; what the sort of process the supplier has to go through, how they qualify, how they bid, how the requirements are formed, how the software is tested, delivered and so on.

Had the public sector prioritised the internal quality; it could have done so. But it chooses not to.

In a public sector IT project the actual softare development is only small fraction of the cost. Other parts. Sales, legal, management, testing, documentation ... have much bigger impact on the suppliers ability to make money. Thus those are the parts you get and that is what drives the cost.

[olau]

Yes! Some organizations are incapable of buying software.

Buying yet-to-be-developed software is easy with the right software company - you just need to provide your problems and priorities, and an open mind and let them manage the process. We do that for our customers, and we have happy customers.

But if you're incapable of choosing a good partner or you let your internal politics dominate the process, then it is extremely difficult. Even with a good development company, a dysfunctional buyer can easily be a factor of 200-500% in lost productivity.

Off-the-shelf software should be easier - you can just try it out. But the wrong organization can easily be incapable of that too, bundling everything up to save money without understanding how much more complex it makes everything and how ill-equipped they are to handle that complexity, never trying things out in practice, writing long spec lists instead, bikeshedding over unimportant implementation details, prioritizing development contract minutia over working systems, putting too many layers between the developers and actual users, going for a big bang.

There are many ways to screw it up.

[TheOtherHobbes]

Software is not about code. Software is a reflection of culture. The code is a means to a social end.

And if everything about a culture is broken - the relationships, the management insight, the goals (collective effectiveness and pride-in-professionalism vs individual ego and greed), the hiring and HR systems, the procurement, the sales - any software that crawls out of the swamp is going to reflect all of that.

[jaabe]

When you buy big enterprise systems you enter contracts that aren’t easy to exit. You also bind so much money into those contracts that you don’t really want to leave them either, even if the company sucks at delivering. Maybe you’ll fight them in the courts for a few years and maybe they’ll compensate you a few hundred million, but once you enter these deals you’re basically in them until the law dictates that you have to do another round of bidding.

I’ve done this with a lot of difference companies and a lot of different development and project management philosophies though, and they all fail.

We’ve gone full waterfall, we’ve gone full agile and everything in between. We’ve done long detailed requirement specifications and we’ve invited companies into the heart of our business, to let them literally work inside our offices sitting shoulder to shoulder with our domain knowledge. None of it produces high quality software.

The highest quality software we have, aside from a few small suppliers, is the software we build ourselves. It’s anecdotal again, but it’s the same story I hear in my network of digitalisation managers across the countries public sector and banking.

[magduf]

With the way government contracts work, you'll almost never get really high-quality software that way. The contractor simply does not have any incentive to do so, as it isn't in the contract. Instead, the contract usually gives them the incentive to drag things out as long as possible and make sure development costs are as high as they can get away with; "cost plus" contracts are notorious for this.

[jaabe]

I’ve worked in the private sector though, things weren’t better there.

[Scarblac]

Does humanity even know how to make quality software of the size where it costs on the order of hundreds of millions?

[jaabe]

It’s a quite interesting question. Our national tax ministry has had almost nothing of expensive scandals over the past 15 years.

Two years ago they setup a focused devops team inside their organisation. I don’t know the exact details of it because my knowledge is from a 45 minute summit talk, but apparently this team managed to build a national scale system in 3 months that actually work. That would have cost them billion on the private market, and would likely never have worked, yet they did it with a relatively small team.

Maybe the problem is scale. I mean, sometimes I wonder why our contract include numerous product owners, key account managers, groups business analysts, project managers and God knows what else.

This is a little unrelated to buying big systems, but when we wanted to build a RPA setup, one of the consultant agencies had an offer which included 6 business side people and one technician. I mention it, because sometimes buying enterprise systems feels exactly like that.

[Scarblac]

Quality software is not just a matter of the customer demanding it.

Medical software usually comes with medical devices. You'd need a manufacturer that is good at developing both the devices and the accompanying software, and have a medical organisation that is good at their core business (being doctors) and knows enough about medical equipment and software to choose the manufacturer that has good quality in both. Even though another manufacturer may have superior or more affordable equipment and not be as good at the software side, etc (if that can even be judged before using the stuff for a while).

And all sides need to stay profitable while doing this.

Who says going for the manufacturer with the quality software is even worth it? Maybe it's better to go for the one with the better MRI scanner and make do with the crap software, etc.

[jacques_chester]

The software market has strong information asymmetry: typically the seller knows far more about it than the buyer. Buyers struggle to assess quality and must rely on other signals ("nobody fired for buying IBM", "everyone uses Giant GloboConsultingCo", "I really like the font" etc).

[repolfx]

Sounds like actually a team size issue. Two guys in their spare time can't create a codebase big enough to have severe agility or maintenance issues. But the moment you ask for a feature they can't handle in that very limited funding envelope, there's going to be an issue.

[Scarblac]

Or they have simple ways to get the data in and out of their software so the features don't need to be in there. The best software stays small and resists having all those features added.