Software Reliability Pt. 1: What Is It & Why Developers Should Care
Remember that moment when you stepped up to the ATM to withdraw some money and it gave you the wrong amount? Or that time when you got debited for an Uber ride you never ordered? I know what you’re thinking, neither of those beats that failure in the aircraft navigation system on your flight to Dubai, right?
Wait, what was that? You don’t recall these moments? Hmmm…maybe it’s because they didn’t happen (or at least I hope they didn’t).
I don’t know about you, but I typically don’t open my favourite apps with fingers crossed hoping not to encounter a Runtime error. That is a testament to the quality of the software, more specifically, its reliability.
This characteristic is arguably the most important in a software system. Unreliable software may result in high costs for both the end-users, as well as the developers of that software. Users are not looking to adopt software that fails on a regular basis and can’t meet the basic needs or requirements they expect it to fulfil, and developers of those unreliable systems are likely to catch a bad rap for poor quality and lose future business opportunities.
Doesn’t Everyone Know What Reliability Means?
I think most developers would have the right theoretical understanding of reliable software. After all, when you press (or touch) the right button on your screen, you expect it to turn on. When you press a particular key on your keyboard, you expect the right key to be registered. So in a nutshell, things should work as they ought to, plain and simple.
For people who consider themselves to be problem solvers, we should understand this pretty well and diligently work towards providing solutions that won’t have our users getting anxious about what input or action might trigger the next system failure.
“Informally, the reliability of a software system is a measure of how well users think it provides the services that they require. More formally, reliability is usually defined as the probability of failure-free operation for a specified time in a specified environment for a specific purpose.” — Ian Sommerville
Software Reliability Can Vary From User To User
This might have crossed your mind, and it’s definitely something to remember. Software reliability is subjective. How so? Users do not consider all services to be of equal importance. Applications may have different services or points of interaction for users to carry out certain functions depending on their needs.
Those different points of interaction mean that there is likely to be different sets of input data being passed to the software, and some input data may cause the software to fail in a way that other input data doesn’t. For example, let’s say you use a social media app to message other people, and in your experience, that data is processed or handled the right way and your messages always get delivered (when the network conditions are right). However, let’s say a friend of yours uses the same app but only to update his or her status, but that action happens to fail regularly.
The two would have different opinions on the reliability of the software because of the different needs they’re hoping to have met by the same application.
Software Faults vs Software Failures
Wait, aren’t these two one in the same? I guess it can be hard to distinguish the two when they’re used interchangeably, but I would argue that they’re not the same.
Software failures occur at runtime or during execution of the program. It is what happens when the system fails to deliver what is expected by the user, just like that fictional ATM situation I mentioned at the start. They are dynamic in nature.
Software faults, on the other hand, are static. They are programming or design errors that cause the software to not align with its specifications or requirements. Software faults can be found in the source code of the program. As you may have picked up, these faults are the cause of the failures that occur in the system when the bad source code is executed with a particular set of inputs which expose the software faults. Developers don’t like hearing this, I know I certainly don’t.
So what does that mean, less software faults results in increased reliability? I wish it was that simple. It all goes back to how users interact with the software. You could develop an app with a very low percentage of faults, but if those faults exist in a particular service that most users interact with, they would consider it highly unreliable. Whereas an application with a much higher percentage of software faults that exist in services that users aren’t likely to use may be considered highly reliable.
You may even have cases in which some experienced users work around software faults which they know cause failures. I’ve had to do this with a particular banking app.
The Engineering Process
I know what you’re thinking, “How on earth do these supposed faults, or as they’re commonly called, ‘bugs’, get into the software?”. The answer to that question is usually (not always) very close to home. The reliability of a software system is hugely influenced by the engineering process, so we shouldn’t look over our shoulders when the people in the room turn to look at the developers. It’s a simple equation:
poor software engineering === poor software quality
Now, I understand that reliability doesn’t always rest solely on the team of developers. If the specifications don’t account for how the software should react or handle exceptions, that does to a great extent fall on the team responsible for the specifications of the software. However, developers still have a responsibility to program in such a way that the system can deal with these faults, but I’ll save the details of that for part 2.
That Being Said…
The daily usage of software will only increase exponentially, and we, as developers, have a privilege of shaping the way it works to meet the needs of others. We, too, benefit from the craftsmanship of engineers who have built reliable systems that help and enable us to carry out a lot of the things we do, whether it’s the IDE’s, the banking or insurance apps, Uber, Netflix and the list goes on.
There’s no denying that engineers behind our favourite software products cared enough to produce reliable software that meets needs, and we should too.
References:
Software Engineering by Ian Sommerville