Introduction

If you're serious about producing an excellent product, you face two problems:

• How do you know when the product is good enough?
• If the product is not yet good enough, how do you assure that the stakeholders involved know that?

The answer to the first question lets you release the product. The answer to the second question helps you avoid releasing a bad product.

You might think: "I don't want to ship a merely good enough product; I want to ship a great product!" Let's explore that. What happens when you tell your coworkers, managers, or investors that you have high quality standards and intend to ship a great product? If it's early in the project cycle, they probably nod and smile. Everyone likes quality. However, if it's late in the project cycle, you're under a lot of pressure to complete the project. Creating a great product might require that you perform extensive testing, fix many problems (even small ones), add features, or even scrap and rewrite a large part of the code. You will also have to resolve disputes over different visions of good quality. Greatness is hard work. Perfection is even harder! Eventually, the people who control the project will come to you and say something like: "Perfection would be nice, but we have to be practical. We're running a business. Quality is good, but not quality at any cost. As you know, all software has bugs."

Greatness can be a motivating goal. It appeals to the pride you have in your work. But there are problems with using what amounts to "if quality is good, more quality must be better" to justify the pursuit of excellence. For one thing, making such an argument can portray you as a quality fanatic, rather than a balanced thinker. For another thing, it ignores the cost factor. A BMW is a nice car, but it costs a lot more than a Saturn. A Saturn may not be the ultimate driving experience, but it's nice for the money. In leaving out cost, the more is better argument also ignores diminishing returns. The better your product, the harder it gets to justify further improvement. While you labor to gold-plate one aspect of a product, out of necessity you must ignore other aspects of the product or even the potential opportunities presented by another project. The business has to make choices every day about the best use of its resources. There are factors other than quality that must be considered.

The good enough quality concept (GEQ) is, paradoxically, a more effective argument than more is better, because it provides a target that is either achievable or not achievable, in which case it becomes a de facto argument for canceling or rechartering the project.

Paradigms of Good Enough

Most businesses practice some form of good enough reasoning about their products. The only ones that don't are those who believe they have achieved perfection, because they lack the imagination and skill to see how their products might be improved.

Here are some models of good enough that have been tried. Some of them are more effective than others, depending on the situation:

• Not too Bad ("we're not dead yet") - Our quality only has to be good enough so we can continue to stay in business. Make it good enough so that we aren't successfully sued.
  
  
• Positive Infallibility ("anything we do is good") - Our organization is the best in the world. Because we're so good, anything we do is automatically good. Think about success. Don't think about failure because "negative" thinking makes for poor quality.
  
  
• Righteous Exhaustion ("perfection or bust") - No product is good enough; it's effort that counts. And only our complete exhaustion will be a good enough level of effort. Business issues are not our concern. We will do everything we possibly can to make it perfect. Since we'll never be finished improving, someone will have to come in and pry it from our fingers if they want it. Then they will bear the blame for any quality problems, not us.
  
  
• Customer is Always Right ("customers seem to like it") - If customers like it, it must be good enough. Of course, you can't please everybody all the time. And if a current or potential customer doesn't like the product, it's up to them to let us know. We can't read their minds.
  
  
• Defined Process ("we follow a Good Process") - Quality is the result of the process we use to build the product. We have defined our process and we think it's a good process. Therefore, as long as we follow the process, a good enough product will inevitably result.
  
  
• Static Requirements ("we satisfy the Requirements") - We have defined quality in terms of objective, quantifiable, noncontroversial goals. If we meet those goals, we have a good enough product, no matter what other subjective, non-quantifiable, controversial goals might be suggested.
  
  
• Accountability ("we fulfill our promises") - Quality is defined by contract. We promise to do certain things and achieve certain goals. If we fulfill our contract, that's good enough.
  
  
• Advocacy ("we make every reasonable effort") - We advocate excellence. Throughout the project, we look for ways to prevent problems, and to find and fix the ones we couldn't prevent. If we work faithfully toward excellence, that will be good enough.
  
  
• Dynamic Tradeoff ("we weigh many factors") - With respect to our mission and the situation at hand, a product is good enough when it has sufficient benefits, no critical problems, its benefits sufficiently outweigh its non-critical problems, and it would cause more harm than good to continue improving it.
  
  

Is High Quality Necessarily More Expensive?

Depending on a lot of factors, such as process, skill, technology, tools, environment, and culture, you may be able to produce a much higher quality product for the same cost. A more testable and maintainable product will cost less to improve and other costs are specifically associated with poor quality, such as support costs and costs to the customer.

The cost of quality is a complex issue and it's difficult to make broad generalizations. However, you can say with certainty that you can always spend more time on much better tests, much more error handling, and more fixing or rewriting of every part of the product. No matter how good you are, that costs something. And if you can't think of more improvements to make, it's more likely that you've reached the upper limit of your imagination, not of quality.

In the software industry GEQ is inspired more as a response to one particular cost than any other: the cost of not releasing the product soon enough. The specter of the market window, or the external deadline, imposes penalties upon us if we can't meet the challenge. That's why the ends of projects are so often characterized by frenzied triage. If you want to know what an organization really believes is good enough, and how well prepared they are for it, witness the last three days of any six-month software project. See what happens when a new problem is reported on the last day.

Wouldn't Quantification Help?

It can be tempting to reduce quality to a number, then set a numerical threshold that represents good enough quality. This is a problem, because you can only measure factors that relate to quality. You can't measure quality itself. This is partly because the word "quality" is just a label for a relationship between a person and a thing. "This product is high in quality" is just another way of saying "Somebody values this product". It's a statement about the product, but also a statement about people and the surrounding context. Even if the product stays the same, people and situations change, so there can be no single, static, true measure of quality.

There are many measures you might use to get a sense of quality, even if you can't measure it completely and objectively. Even so, the question of what quality is good enough requires sophisticated judgment. You can't escape from the fact that, in the end, people have to think it through and make a judgment. For a simple product, that judgment might be easy. For a complex, high-stakes product, it's very difficult.

Further Information

To assist you with evaluating product quality, the following types of information are available for most of the artifacts included in the Unified Process:

• Artifact Guidelines and Checkpoints: information on how to develop, evaluate, and use the artifact.
• Templates: "models" or prototypes of the artifact, providing structure and guidance for content.