More On Broken Software

It’s not as if I’ve been lying awake at night worrying about writing software (OK, perhaps slightly) but I have been pondering the “Is everything broken?” question a bit. And I’ve come to the conclusion that, at the end of the day it probably is, but then again it doesn’t really matter that much.
All of the terrible examples that are quoted are irritations in the great scheme of things. Nobody has been hurt, nobody is going hungry because of them and if the worst thing that happens to you in your life is that you can’t put any more music on your iPhone then I really, really, want a life like yours. True, it is annoying that things don’t always work as they should, and true, it would be nice if people felt moved to provide higher quality than they sometimes do, but at the end of the day stuff mostly works, and that is the important thing.
Technology now lets us do things (albeit imperfectly) that we just could not do before. It is also a great leveller. The Queen might have an iPhone that is covered in precious stones (although she might deem that a bit tacky) but she can’t do anything with it that you can’t do with yours. Although she might not worry as much about roaming charges as you do. The best phone in the world, whatever that is, can be obtained by literally millions of people, not just one or two. And, what’s more, anyone can make programs and sell them on the devices, providing a path to riches that just wasn’t there in the past.
I think, at the end of the day, we are always going to be upset with the status quo, and want it to be better. I vividly remember reading a piece some time back that was written by a retired general type. He was moaning about the way young people were more useless and lazy than he was in his day, and how their lack of discipline and application would lead to the collapse of civilisation as he knew it. Turns out he was a retired general from the Roman Army and was writing this a few thousand years ago.
The best thing to do is to take these issues on board, try to move things on a bit and give our children something even more fantastic to complain about when they get to our age.


Reader Comments (6)
The scariest software that I ever wrote controlled great big milling machines that made things like airliner wing spars. I was always very conscious of the fact that a missing decimal point could cause an awful lot of physical damage......
I think it can be a mistake to rationalize-away mediocrity. These points about crappy software are valid. This is more of an eye-opener that we (as software professionals) should maybe step-up our game a bit.
In other words, why NOT have great software? Why not have a higher standard of what we (as users) will accept? What is the downside? The downside is that "it's harder and will take more time" for the developer. Put another way, software is crappy because developers are lazy (bless our hearts!)
So although you are right - we all have better things to do than complete about bad software. However, there is an opportunity here for all of use "professional" software developers to maybe bring up our game a notch and try put out better software!
-Rob (no, not you, I'm a different Rob!)
I once wrote a program that hit the spec. and worked perfectly with the 20 items I was told it was going to be used with. Then, when the users gave it 100 inputs, it started to grind a bit. I was told that they didn't think it was important to tell me that the number of inputs had been increased. I bet you'll find that lots of the problems that people are encountering are problems of this nature, where you can't really blame the coder for doing a bad job, it is more that changes in the ecosystem into which the program is placed that causes the problems. And if the coder starts to make assumptions about where the ecosystem is going, that can cause problems too. Imagine the moaning that you'd get if a system reserved space for 10,000 contacts when most people only have 100.
Perhaps a much more important point (which I completely missed) is that the true measure of the greatness of a system is how it well responds in failure mode. At the nub of a lot of the problems that are reported is a failure by the makers to even acknowledge there is a problem, let alone fix it. That is never acceptable. If someone reports a bug in my software I work very hard to make them a happy user again. Companies these days appear content to play the percentage game on this, and seem to be able to live with a number of their users who are very unhappy with what they provide. Hopefully, with the rise of social networking it will be impossible for companies to play this game, read "The Thank You Economy" for more on this. Cynical me says that what will really end up happening is that companies will become better at "handling" complaints, but it should move things on a bit.
Behaviour Driven Development..
http://www.codeproject.com/Articles/32512/Behavior-Driven-Development-with-NBehave
Or maybe:
Alistair Cockburn's "Writing Effective Use Cases".
At any rate, the issue here is that when any item is sold, it imposes certain legal obligations on the seller - in particular the 'merchantability' of such goods. If users were buying the software rather than just buying a licence to use it (I.E. ownership of the copy of the software was transferred with the purchase) then I suspect that selling defective goods and services would be dealt with much more harshly.
In the end, all software is mathematics and binary maths at that.