What's in a Word: Quality

(This post originally appeared in German on innoq.com)

The aim of this short post is to show how broadly people can interpret and understand the term quality – and why this leeway is highly risky in software architecture. It is the first installment of a mini-series).

Let's start with a definition:

Quality (from the Latin qualitas, state, feature, property, or condition) is the sum of all properties of an object, system, or process.[^wikipedia-definition].

Let's restrict ourselves to all the properties of a system, and leave processes aside.

Quality is the same as „good“

Colloquially, we use the word „quality“ as a synonym for properties or things that we consider „good“ or „excellent“. This however results in all manner of ambiguities and double meanings. Only in some cases, the concrete meaning can be inferred from the context.

With regards to quality, this concrete meaning often remains unclear („implicit“) instead of being explicitly explained. What „good“ means with regard to an everyday object requires a subjective interpretation.

Let me illustrate the problem of this ambiguity with the example of audio (tones, sounds, music).

Audio Quality

Ringtones, alarms, acoustic signals made by our computers, the low-battery warning of our home phones, or even the morning alarm clock radio – tones and sounds („audio“) are everywhere in our technological world.

Fun fact: audio also comes from Latin, and means „I hear“. [^wikipedia-audio]

To get attuned, you can listen to an example below (or just carry on reading).

Some people talk about audio quality, or properly speaking about „high“ or „good“ audio quality.

But what do they mean by that? Have a quick think and try to define more precisely what „good audio quality“ is supposed to mean exactly.

Imagine an important person („stakeholder“) has stated „good audio quality“ as a requirement.
You and your small team have a delivery commitment and have to meet this requirement.

(Please briefly think for yourself)

The sound sample above probably didn't help in your thinking, unless you listened to it with stereo headphones ...

Let's address a few possible interpretations of the term „audio quality“:

We could interpret audio quality as the most faithful reproduction of the recorded sound or piece of music possible, with the least possible interference resulting from recording and playback. In this case audio quality encompasses not only the audio file itself but also the transducer (e.g., headphones or loudspeaker). An example for this – a saxophone recording from Yoyogi Park in Tokyo:
We could consider audio quality solely from the perspective of the audio file – which in this case may have to be below a certain file size, for example because we want to save it to an extremely limited (embedded) computer.
Maybe we like stereo and surround-sound effects. Audio quality means that the channels have different signals. This can be seen for our sound sample in the diagram below.

Audio quality can also mean that we want to record a sound source with frequencies of up to 200 kHz in order to hear sound waves outside of the audible range of humans, as used for example by bats for navigation. This would require a sampling rate of up to 400 kHz.
For some people, audio quality may also mean being able to listen to music as loudly as possible, for example because they need to provide the audio for an open-air concert. The hardware plays an important role with this requirement, because high volumes require serious amplifiers. In this case we will probably have to pay close attention to eliminating static as well as limiting spikes in the audio signal.
In contrast, others want to filter out ambient sounds through the generation of compensatory sound waves (noise cancelling). The term „audio quality“ refers here to the transducer (e.g. headphones).
Perhaps we are science fiction fans and like it when human voices sound as distorted and „spacey“ as possible. In other words, quality means that voices are doctored by means of effect filters. An example with and without such effects:

Last but not least there are those who like hall and echo effects, and to have more bass in the music. Below is a before and after sample adjusted according to this interpretation – listen to them one after the other for comparison:

By now at the latest, you should be asking how our (hypothetical) development team should produce audio quality.
The interpretations presented above are mostly mutually exclusive – it is impossible to fulfill all of them at the same time.
And yet taken in isolation, all of them are plausible, at least in my opinion.

Clarify requirements of audio quality

Let's play the role of „stakeholder“, and set the following requirements for our audio sample.

Our audio should:

Be recorded (or generated) in stereo with a minimum 44 kHz frequency rate
Have clearly audible differences between the left and right channels (15% or more)
Have a file size of 200 KB or less
Be coded in a standard format like WAV, FLAC, Ogg, or MP3
Be usable under a Creative Commons license In contrast to many other requirements this is not technically actionable, but only organizationally.

While these requirements are certainly still far from perfect, they are a step in the right direction in terms of concreteness and precision – and easily verifiable for a development team. As a requirement, this is in my opinion much more appropriate than the phrase „high audio quality“.

In reality a range of stakeholders play a role, each bringing their own interpretation. Software architects and development teams must then be able to identify potential conflicts and contradictions, and resolve these with the stakeholders.

Quality in software

When already the term „audio“ subsumes this many potential interpretations and individual features, how will it look with the much broader term „software“?
In the following diagram I collected a few terms related to „quality of software“.

Many intelligent people have already described at length how we can make the term „quality“ more concrete or more precise. Unfortunately, a lot of this advice has not reached many development teams and product owners.

Take a look at the article on quality storming by my colleague Michael Plöd – you will find a lot of constructive advice there.

In addition, at arc42 there is a collection of (freely available) examples of concrete quality requirements - although I'm afraid much of this material is still in German and needs translation..

Sources

The sound samples come from Freesound.org,
The spoken sample from Text2Speech.org
I talked about quality as a driving force at a technology lunch. The recording (approx. 30 minutes, in German) can be found here

Thank you

Thank you for reading this far – hopefully this post will have sharpened your awareness of the importance of concrete and explicit quality requirements.

If you (or your colleagues) prefer to watch it as a video, it's available (in German) on YouTube.

Many thanks to Matthias Deja and Joachim Prätorius for their constructive feedback.