richrtesting

This is a post with two purposes.

Quality is a nebulous concept and I talk about it regularly. I talk about it with my colleagues and I mention it frequently in my posts on this site. I might not have a Phaedrus level fascination with the subject, but I probably mention it enough that I need to explain what I mean by it. So the first purpose is to answer the question myself; what do I mean (and not mean) when I mention quality?

The second reason for the post is to ask you to ask yourself the same question. I should probably clarify that. The request is to ask yourself (and possibly your colleagues too if you are feeling like being a nuisance) what you (or they) mean by quality when using the word in a software development context. I will explain why I think this is important shortly.

What do I mean by ‘Quality’?

Let me preface this by emphasising that I understand this is a personal definition and opinion. There are plenty of other definitions of quality, some of which have heavily influenced my interpretation, and some of which take a different tack. I’m not suggesting that there is a ‘right’ or ‘wrong’ definition, just that this is what I mean by ‘Quality’.

Here’s a definition:

Quality is a subjective and variable impression of a product or service, instinctively reassessed and recast with each interaction.

This first appeared in a tweet a couple of years ago. I explained it in a subsequent blog post and again in my book, where I explained the definition a bit more.

Central to the definition is that the impression is one a person forms of a product or service. To me, the focus on the human in the relationship is crucial, particularly in software development; a field where quality is often measured according to very technical criteria. A person’s perception of the quality of a product is based on a  multitude of aspects but when I refer to quality I have the product, the person using it, and their experience whilst doing so in mind.

This is what I mean by ‘Quality’.

What do I not mean by ‘Quality’?

Sometimes when people talk about quality in software development, I feel they are talking about the standard or success of the things that surround the way a product is conceived, designed, developed and maintained. By this I mean the methods and techniques adopted, the organisation or team culture, and so on.

I absolutely recognise that all of these factors can play a part in the resulting products or services, but I believe there is an important distinction between product quality as perceived by a person (often at the point of use) and the steps we take or mechanisms we put in place to influence that perception.

For me, these factors are better captured under the broad umbrella of Quality Assurance. Paying attention to them is vitally important because they can each contribute to the impression a person forms. We can make adjustments to them in an attempt to create a more favourable impression and clever, innovative ideas emerge as to how to make these adjustments in software development.

But, this is not what I mean by ‘Quality’.

What do you mean by ‘Quality’?

Perhaps you already have a good definition of quality in mind; maybe Gerald Weinberg’s ‘value to some person’ or maybe you subscribe to Philip Crosby’s definition of quality as ‘conformance to requirements’ or perhaps something entirely different.

If you don’t have a definition in mind, perhaps you at least agree, or (maybe violently) disagree with my distinction between the quality of the product as perceived by a person and quality assurance of the factors influencing this perception.

When discussing quality I think it is important to clarify our own intentions, and perhaps to seek an understanding of what our colleagues mean too. Often quality is included in statements that might initially sound clear but could lead to confusion, assumptions and misunderstanding.

People will say things like “We shouldn’t compromise on quality”, or “If we increase speed we will improve quality”.

If “conformance to requirements” is your thing, then ‘not compromising on quality’ probably means making sure requirements are fulfilled. Yet, someone who finds themselves in agreement with Gerald Weinberg’s writing could point to the section on ‘The Relativity of Quality’ in How Software is Built and advise that conforming to requirements will only be of use if we have a good understanding of whose requirements we are concerned with.

A DevOps advocate might point to the ‘State of DevOps’ report and highlight the references to improved quality in teams adopting continuous delivery practices. The report includes measures such as Deployment Frequency, Mean Time To Recover, percentage of work performed manually, time spent on unplanned work and rework versus new work. These measures, which are taken as proxies for quality, focus heavily on the methods and mechanisms of development teams, but are distinctly light on the human responses of customers. Those who apply a more human focus to their definition of quality may find such measures unappealing and inconclusive.

It seems to me that in a software development team, discussing such differences of opinion would be useful conversations to have.

Yes, quality is a nebulous concept and the path of least resistance is to operate on a shallow understanding of the word, but I for one would welcome opinions on what quality really means to you.