What Is Software Quality?

Quality is one of those things that everyone wants at the end of a software project but rarely does anyone have a good idea of what it is.

Like so many things in the software world it's hard to define or even get people to agree on what it is. A popular joke among rabbis is that for every two of them there are three opinions and I think programmers probably follow the same pattern.

To me quality in software is many things, some relate to the end user, some to the developer and some to the management. It's not one thing at all but a lot of different aspects. People might disagree on which of these is more important but I think they all have merit.

The first type of quality is how the software acts when it's being used. My favorite idea is "the software always does what it's supposed to do and never does what it's not supposed to do". Another adjunct to that is that software should not be surprising. When you use it everything works as expected and you never see it do something wrong or odd.

When I get in my car and drive somewhere I expect it to get me there without any problems. To me a car is how I get places and if I can't get there every time I feel like the car has low quality. Likewise software should just work. Of course it's not that simple since software might rely on an OS and hardware and networks and servers and who knows what might cause it to fail. As programmers we know that no software is an island but users simply don't care, if your software crashes or does weird stuff it's your fault! This makes software quality difficult to find sometimes but doesn't mean we shouldn't try to get there.

Assuming your software works correctly there are of course other types of quality. If your app works great but the design or usability is terrible then it's not really a quality program. In my early days of programming in the early 80's designing UI (as it was known then) was not really important. As long as people could do something with the software then it was good enough. People were amazed that they had computers to do anything at all. As software began to mature and gain more functionality then UI became more important to consider. Young UX designers today are amazed when I tell them that UI was a programmer speciality for much of my career. Even today building a quality UX is not an easy thing and horrible designs are still around us. But if someone can't use some software effectively then it is really missing an important quality.

Of course for your software to work well it has to be well designed internally as well. Design (or architecture, which to me is design on a bigger scale) of software is still not a science given the enormous variety of different kinds of programs you can write in varied and constantly changing languages, frameworks and environments. People who specialize in bridges just build bridges which are mostly the same. Software is radically different and more often than not you are designing something for the first time with only a slight similarity to your last job.

Design quality is often a contentious concept among programmers who disagree on the right approach, if in fact there is such a thing. Good design leads to many different aspects of quality.

Among the design qualities is maintainability, which means the software can be extended into future additions and changes without a lot of pain. Another is application performance, which may not matter for some kinds of applications but may be critical for others. A third is productivity, a well designed program amy be easier and quicker to complete. Good design also leads to testability which is necessary to create the quality the user expects actually be possible.

Quality of testing is often the differentiator between a quality application and a terrible one. I am constantly amazed at the bugs I see in supposedly quality applications from well known companies. Perfection is of course only an ideal, but if you don't treat testing seriously then none of the other qualities really matter.

I worked for game company for two years fixing bugs but it was too late; their lack of interest in testing and quality cost them most of their customers before I came. The challenge of fixing all this crap was a lot of fun but working for a slowly failing company was not. Even though the game was fun and the customers loyal eventually if they couldn't play because of all the problems, they just left sad (or mad).

If you've done a marvelous job writing a perfectly functional application with an amazing design that oozes quality, but it doesn't do something (or anything) the user needs to do, then you have a lack of utility. If you never figured out what the user or customer needed, or the information was garbled by your process or poor communication or you never asked the right questions, then the software might be useless. It's an important quality since without it no one cares what else you accomplished.

There are still more qualities than people sometimes forget. If you have this marvelous, well designed, functional application that will cause immediate customer delight but none of them know it exists then you are missing marketing quality. It's a funny concept for a programmer but I've been around enough companies with no clue on how to connect customers with their products. If a tree falls in a forest does it make a sound? If your software is used by no one does it have quality? Who cares.

One final thing which I know many programmers hate to think about is still a measure of quality, of sorts. That is business success. It's a final quality where if you don't get enough of it nothing else matters other than your personal pride since you will looking for a job! Of course programmers rarely have any input into this one.

The funny thing about all of these qualities is that you can succeed in the last one and still fail all of the rest. I think it's the most frustrating thing is to work on a great quality product and then see a total piece of crap get all of the business success. Sometimes all you are left with is quality swearing.

Writing code is probably the thing most of us do the most, but it's only a small part of the overall quality of what we produce. None of these things on their own make a quality application, you need all of them to work together. If you can't do them all by yourself you need to be part of a team that takes a holistic approach to quality.

Even if we disagree with the details, I hope we can all agree that seeking quality is itself a good quality to have!