Dieser Blogpost ist auch auf Deutsch verfügbar
Another definition from our mini-series: This time we’ll look at the term quality.
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.
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.[1].
Let’s restrict ourselves to all the properties of a system, and leave processes to one side.
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, the concrete meaning of which can sometimes 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).
Quality of audio
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“. [2]
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 have a brief think.)
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:
Saxophone in a park (with ambient noise)
- 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.
Stipulating the 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 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 individual features, how will it look with the much broader term „software“? In the following diagram I have collated a few terms related to the subject „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 (and will no doubt be the subject of a future blog post).
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.
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.
Other posts in this „series“
If you have an IT-relevant term that you would like to have explained here, please let us know.
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
- Quality Driven Software Architecture: An older but still relevant article on quality as a driver of architecture decisions
- Qualitätsverbesserer – part of the book Knigge für Softwarearchitekten, published by Peter Hruschka and Gernot Starke (in German).