The quality vs your quality

Thoughtworks released a new version of their Technology Radar. Essentially this is a map meant to help people understand and rate software engineering trends and technologies.

An interesting development consists in the increased profile for metrics and visualizations. I am happy that finally practitioners start to recognize code analysis as being important. There is indeed a great body of research in this field that can be of great use for practice.

But, even if metrics and visualizations appear at the very center of the radar (hence very important), they are not yet well understood. Take a look at the following statement from the July version of the radar:

Measuring software internal quality is still a mystery.
Technology Radar, July 2011

The authors feel code analysis is important, but they just do not know how exactly to use it in practice. This pretty much reflects the opinions of most practitioners I encounter.

Let's take a closer look at the statement. I do not know if they meant it like that, but the word "still" denotes a slight exasperation that seems to say "after all these years of research effort and promises we still cannot utilize the results."

And it is not because of lack of effort. There is a large body of literature on this subject, and there are significant advances, too. The art and science of measuring software aspects has come a long way over the past two decades. Still, even if the technical aspects of how to attach numbers to software facts is well understood, capturing quality in the large still evades us. This is frustrating.

I believe the root of the problem comes from the underlying meaning of quality. When people talk about software quality, they usually talk about the quality. The quality is the globally unified understanding of what is good and what is bad about software systems. This is indeed a mystery, and will most likely remain so for the foreseeable future. From this point of view, the quality shares commonalities with the Holy Grail: they are both supposed to be real, they both come with great promises, and they both remain elusive.

Software is too complex, and it lives in too many contexts for us to be able to have a global and quantified view of its quality that is still meaningful. But, what if measuring the quality is not that relevant for daily business?

To measure something, you first have to be able to say what that something is. And, we just cannot say what the quality is. Or, to put it in the words of Christopher Alexander, this quality has no name. Better still, it has no single name.

Quality is highly contextual. If you ask an engineer about quality in general, you will likely get yourself into a philosophical debate that can last for hours. If you ask the same engineer about comparing the quality of two hands-on solutions within the context of your system, you will likely receive a decisive answer within minutes.

Your context makes all the difference. Once you know the context, you can start to instantiate general patterns and make them operational. This is what leads to action and to engineering solutions. This is not to say that concerning ourselves with the quality is not important. It is. It is this effort that helps us identify general patterns. However, you will not be able to measure it directly.

Instead focus on your quality. Learn to embrace it. Learn to measure it. Learn to manage it. It is your quality. Make it yours. It might look like a compromise, but it brings value.