Three-Dimensional Quality

One of the most common questions I get as a quality coach is “So what is quality?”.

For a long time I tried to dodge the question. “Quality” is a vast and complex topic.

I use a model to simplify quality into three important dimensions. This isn’t meant to be a perfect representation. To quote Dan North, “All models are wrong; some are useful”.

Internal Quality

Some aspects of quality are primarily of importance to the creator, rather than the audience. I call this as “internal quality”.

We have history of this in software engineering. Test coverage and cyclomatic complexity are attempts to measure the internal quality of code, (and another example of a wrong-but-sometimes-useful model).

Code review and pair programming are practices to encourage accountability for internal quality between peers. In fact, much of the software craftsmanship movement emphasises the importance of internal quality.

External Quality

Some quality characteristics are all about how your audience experience what you deliver.

We treat design as a differentiator for Redgate’s products. We have exceptional UX designers who help teams deliver tools that are ingeniously simple to use.

Design and user experience aren’t the only facets of external quality.

The idea of bugs is so prevalent throughout software, and they’re an obvious detractor from external quality.

Scope is a huge, often overlooked, factor in the external quality. Offering too little is “not good enough”, while too much is “bloated”, “unappealing”, and “difficult to use”.

Procedural Quality

Internal and external quality are generally measures on what you produce. I also see huge quality implications for how you produce.

Gathering feedback is wonderful, but where does acting on that feedback factor into how you work?

What different feedback loops do you have, and how long do they take to give you meaningful feedback?

How do you deliver what you’ve produced, and how does that meet the needs of those who are receiving it?

How is this useful?

Broadly, I find this useful in two ways.

1: Communication is hard

Way back in the intro I mentioned how vast the arena of quality is. People will naturally lean towards different aspects of quality, based on their prior experience and motivations. By talking about a big, amorphous “quality”, we make our conversations incredibly difficult.

By talking about different aspects of quality, we can better share our own thoughts and build a shared understanding of exactly what we care about.

2: Decomposing problems

In every team I’ve worked with, it’s been possible to dramatically improve each of these different axes. By identifying the subdomain of quality you want to improve, you can be far more deliberate in how you go about improving it.

Relentlessly improving just one aspect of quality will only get you so far, though. I’ve worked with teams who relentlessly improve procedural quality, and wonder why they stop improving after a while. Every time it’s been because some other quality axis is letting us down, and is constraining our ability to grow.