Software reliability

Endless volumes have been written about the problems associated with the growing complexity of software. It is interesting how the ancient story about the tower of Babel seems to be materializing in the form of broken communications between software applications located on different hardware products and vendors.

I don’t claim there is a silver bullet that would solve this, but there is one thing I’m certain of, and that is that a lot of this mess has to do with doing things fast instead of doing them well, complicating instead of simplifying, building huge buildings without first taking the time to make sure they have rock-solid foundations.

This is obviously a generalization, and as such has its exceptions – but I’m referring to much of what I’ve experienced over many years in a wide spectrum of development platforms, software products, SDKs and what not.

I suspect part of the reason for what I call the “race for quantity at the expense of quality” has to do with the Western way of life and its financial driver – i.e capitalism. This philosophy tends to orient people more towards quantity than towards quality, resulting in companies wanting to churn more and more features so their products will have more check marks than their competition in the competitive analysis chart.

But this also has to do with caring enough about the people who are going to use your product. This is something that can be improved by just starting to give a damn about making your product simple and reliable to the point that there is no room for ambiguity or question as to how to make it work.

There are so many examples of this that I probably don’t have to specify – any software developer has come across them. Hours or days of research that result in an answer that had it been documented, would have put the problem to rest in 5 minutes. As another example – endless code with bad documentation that upon inspection can be reduced to code a fraction of the size and simple examples that would provide much better help than any documentation would. Sites like Stack Overflow are great, but in a way many of the questions posted there stand as evidence of this problem.

The trigger for this post is me currently wasting time trying to understand why a very simple code example does not work as advertised in a certain commercial product. I’ve been through this before and I’m experienced enough to know that it has nothing to do with the code logic. The question I’m asking myself is “why do I have to waste time on this ?”. As a consumer, you wouldn’t put up with buying a TV, turning it on, switching it to the channel you like, only to find an error message on the screen saying “Error: situation not anticipated, please configure the firmware accordingly”.

Keep it simple. Keep it reliable. Strive for better instead of larger – this might not solve the software complexity issue, but at least it won’t make it worse.

Leave a Reply

Your email address will not be published. Required fields are marked *