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.
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
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
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.
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.
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.
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.