I said in a previous blog that software failures are a regular occurrence. You might wonder why you haven't heard of many in the news. In part, it's because many of the failures I refer to are failure to deliver, rather than caused a huge accident that resulting in loss of life. Such failures aren't really interesting news (except perhaps in the business section). Defining what a failure is is complicated. Even failure to deliver has many shades, from just gave up completely to did not deliver on all functionality that was asked for to does pretty much deliver the required functionality but using the thing is like a tooth extraction without anaesthetic.
There is a joke about research being like shooting an arrow into the air, and declaring where it lands to be the intended target. I sometimes wonder if many software systems are like this. They start with grand plans and ambitions, but as time passes and the goals aren't met, a certain weariness creeps in, people become dispirited, and eventually whatever the thing does at the moment is declared to be the target system. I know this is not universally true. I have talked to any number of developers who have built systems they are truly proud of (and deservedly so), but I've also encountered (as in personally used) systems that probably aren't considered failures but perhaps should be.
Whether such examples should be consider failures is somewhat in the eye of the beholder. But consider the following exchange: "You know that 11 story building we're doing for you? Well we got to 10 stories, and we're already late, and we've got other things we need to do, and you guys want to move in, so how about we just stop there?" I'm sure there have been such cases (perhaps not so extreme) but generally this would be considered unacceptable.
Perhaps a more realistic scenario is when the client's desires are a little ambitious. If it was an 110 story building, and the discussion went "Sorry but there's no way we can build that in the time you've given us and the budget you have." Then there would be no surprise. But usually this would take place well before the bulldozers move in. The difficulty with software is it's not always obvious what is overly ambitious for a software system until construction has begun. So maybe it is a little unfair to declare such a failure.
Then there are the cases where the system kind of works, but is also somewhat annoying to use. I recently was at a conference that provided two apps to help delegates navigate the various sessions. They provided the schedule, including what the presentation was and where it was, as well as other conference information. However if there was a particular talk you knew was going to take place, neither of them provided an easy way to figure out when or where that talk was. The only way was to go into each session and look. There were 4-6 sessions each period, 4 periods during the day, and 3 days of conference. It was faster to pull out the paper programme and look at that! This was the top conference in software engineering in the world. Sigh...
In part, we get what we ask for. We have been taught to accept poor software systems as being all that we can expect, and so for a long time only a minority have complained. Fortunately people's expectations are starting to change. When everything is an app, and there are 20 apps that do roughly the same thing, we expect to be able to find something that we can easily use. You see this also in some on-line applications. Bank websites for example have significantly improved in how easy and convenient they are. Unfortunately there are still many systems that seem more trouble than they are worth.
But back to actual failures. There have been some that have been recorded (more in a latter blog). There are have been a number that have been suspected but for various reasons we can't confirm. And there have been likely many that we may never get to hear about. This is unfortunate in a discipline that claims to do engineering.