I’ve worked on numerous software projects in my career so far, and not a single one was ‘perfect’ in terms of quality - there was always something that could be done better, whether that be more maintainable, more secure, more performant, or any number of other improvements. I’d like to believe I pride myself on producing ‘quality’ software - but did I actually accomplish that?

I believe I did, at least to a degree. And that’s part of the challenge to myself - measuring that ‘degree’. I’m setting out to define for myself what quality software actually is, how to measure it, and, if all goes well, create a systematic way of measuring quality in software I build going forward.

This will be the first in a series of posts about software quality. First up, defining it with some background!

What IS quality in terms of software?

There is a well-defined way to evaluate the quality of software products - the ISO / IEC 25010 Software Quality Model. The model breaks down what software quality encompasses into 9 characteristics with nearly 40 sub-characteristics (at least at the time of this post going live). While on paper this makes perfect sense, when I was first exposed to this, it was quite difficult to wrap my head around and actually apply it to a piece of software.

Don’t get me wrong, some characteristics are quite straightforward - performance efficiency, for example. It is easy enough to follow that we expect certain response times from software; it should efficiently use the resources available to it and have sufficient hardware capacity to perform its functionality appropriately. However, not all are as easily followed, especially with some using fairly esoteric language such as “appropriateness recognisability.” It can often feel very theoretical without realistic scenarios or examples.

Even with some that are easily understood, it doesn’t necessarily help with measuring your software and assessing whether it is high quality or not - and nor should it really. Software products are so vast and varied, it would be impossible to create a standard set of measures by which you could assess any piece of software. It is more abstract than concrete in defining the quality of software.

That being said, I believe this model does a fairly good job at representing what should be considered when evaluating the quality of software. Whether you’re brand new to this (in which case it will give you great direction in what to look at) or a seasoned veteran (it can help fill some blind spots you may have), the model is a useful tool that you should be aware of and keep in your toolbelt.

In future posts of this series on quality, I plan to unpack each of these characteristics in more detail with some tangible examples and tools to use to measure software quality in that characteristic.

Why is quality important?

Quality is often compromised on software projects - new features and user demands often take priority over quality improvement efforts. It is also HARD to always build high quality up front, as initial solution designs don’t always lend themselves well to shifting business requirements, and without the appropriate time to adjust the solution design appropriately, corners are cut to make new features work.

So, if we’re getting the features out, why does the quality of it matter? Well, there are a number of reasons:

1. Competitive advantage - your users will use your product over lower quality alternatives (or vice versa, they will leave your product for better competitors!).
2. Security being a core quality characteristic, leaves less chance of sensitive data leaks or malicious actions done on users’ accounts, something that can leave a company’s reputation in ruins.
3. Functional suitability of a piece of software checks for not only doing what was designed correctly but also if what it is doing is what the users even want.
4. and the list goes on…

Poor decisions early on can have lasting impacts on the quality of software.

Ultimately though, it comes down to the money. Is the risk of a poorer quality system going to cost the company more than not spending the time and money on building a higher quality system? This is incredibly hard to quantify, especially when some risks may never materialize. That being said, I think a good rule of thumb is that while quality may not matter as much early on in a product’s life when it has fewer users and fewer features, it becomes increasingly harder to improve the quality of software when it was not designed with quality in mind up front. Poor decisions early on can have lasting impacts on the quality of software. There’s even fairly common humor in the industry around this concept - “There’s nothing more permanent than a temporary solution.”

What next

Alright, so we’ve got a fairly high-level understanding of software quality characteristics and why it’s important, but what do we do with this? Well, over the next few months, I aim to unpack each of these characteristics in a series of posts, delving into what the characteristic is about and how one might measure it in a real scenario.

Bear in mind I will be focusing this around my experience in web, backend services, and cloud technologies, but reach out if there’s another area of software that you’d like me to delve into, whether that be native mobile, streaming, gaming, etc.

And otherwise, you can also find my socials on the same page to follow me for the next posts in this series - delving into the quality characteristic of functional suitability!