Q

Remember Q? He is a fictional omnipotent being from star trek. Being uninfluenced by time and laws of physics, Q can overcome all but the other members of the Q Continuum. A nasty piece of work. However, that is entirely what this article is not about.

In fact, this article is about the exact opposite of a nasty piece of work, which is a neat piece of work. It's about Quality, or short: Q.

Is Q important?

Answer 1: "Sure, but not now" .
More often than not, time-to-market is considered more important then quality. This surely is Microsoft's phylosophy about product development: Put in on the market first, fix Q later.

Answer 2: "Yes, people's lives depend on it".
Think medical devices, airplane control systems, nuclear energy plant emergency systems. Obviously, such systems are among the neat pieces of work.

Answer 3: "Sure, but I want to have it for free".
This is what I always see in the projects that I am participating in (is that just me, or what?). In the best cases, quality requirements are made at the project's inception: We want high performance, high robustness, high availability, high reliability, high user friendlyness, high everything...except cost. Often, these requirements are very poorly quantified. Please be very specific about your Q-requirements. How in the world are we otherwise going to be able to measure it and prove afterwards that the required Q has been achieved?

Of course, in the worst cases, Q is a somebody else's problem: no specifications whatsoever are made on quality. In these cases, Q will become a very costly issue. Q will make it's first appearance as a minor priority issue in the the project's problem and issue tracking system. But it will become more and more important over time as actual system and acceptance tests will point out that the system is way too unstable and that it is a good thing the intended users are coffee junkies. Arrived at that stage, Q becomes an enemy that is very hard to overcome indeed.

What is Q anyway?

Here's wikipedia's definition of quality: the non-inferiority, superiority or usefulness of something. Huh? So, if a product is considered highly usefull, then the quality of it is high. Could it be that simple? Would you say that a website that is very user friendly, very fast and very up-to-date but is unreachable half of the times you access it, is of high quality? No, the unavialability will annoy you, rendering the website useless in spite of its other qualities. This makes me wonder: Could Q really be just about usability?

They way I perceive Q is as a set of demands made upon a product that say something about the usefulness of the product. You should always attempt to have a very clear idea of how critical these demands are for the overall usefulness of the product. Would it be bad if amazon.com would be down half of the time? Hell yes, but probably not for pimpyournailclipper.com. Next attempt to quantify the critical Q demands as precisely as possible. And make sure that these critical Q demands are assured throughout the development process.

Instances of Q

Examples of Q instances are:

• performance
• user-friendlyness, ease-of-use
• maintainability
• dependability, reliability
• acuracy
• actuality
• availability
• adaptability
• flexibility
• portability
• compatibility
• safety, security
  

Is assuring Q easy?

If Q is specified sufficiently SMART and measured and maintained throughout the development process, than QA could be easy. Quantifying quality can be challenging though. For example, how do you quantify user-friendlyness? You can't, but luckily, it can be tested.

But no matter the demands you make on a product's quality, make them as clear as you can, as early as you can and verify. I guess I can conclude with: Q is simple, but not necessarily easy.