Quality? What are we talking about?
I had a long talk with some people today on the meaning of Quality.
Of course, as a software developer I consider it to be excellence in coding, that something we’ve written (or had written for us) is correct, expressive, well-structured, reliable, and performant. No wonder we argued so long about it. That’s a lot of ideas for one word.
Now, we had a more classically TQM trained fellow in the room, and he gave us quality as “fitness to purpose”, which is really a definition that I would attribute to excellence in requirements management. That is also quality. This is a definition that works equally well for table oranges (beautiful, regular, colorful, but flavor not so important) and juice oranges (sweet, tangy, tasty, juicy, but appearance doesn’t matter).
Of course, another definition is that it anticipates and provides for user’s needs and desires. That is a “quality product”. The iPod is a quality product in this regard, as is most of the software you happen to like (most likely). Really great games consider the user in this way.
Sure it’s all quality. We have an ideal product if the requirements are selected well, the analysts who conceived the product were sufficiently sharp and imaginative, and the software that rolls out of the development team is correct, expressive, well-structured, reliable, and performant, and if the entire project is available at an acceptable cost (or for free).
All I really learned is that we have to be careful how we express ourselves. My TQM colleague suggested that maybe the thing we need is to begin each project with a discussion of quality so that we can come to a common understanding of the qualities we want our product to have. That sounds pretty wise, to use communication and collaboration.


