Anyone who is serious about producing an excellent product faces two problems
in particular: How do I know when the product is good enough? If the product is
not yet good enough, how do I 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 may be thinking "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, management 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 are under a lot of pressure to complete the project. Creating
a great product may require that you engage in 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,
to make such an argument can make you seem like 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, you must necessarily ignore other aspects of the product,
or the potential opportunities presented by other project. The business has
to make choices, every day, about the best use of resources. There are factors
other than quality that it must consider.
The Good Enough Quality concept (GEQ) is, paradoxically, a more effective argument
than More is Better, because it provides a target that is either a) achievable,
or b) not achievable, in which case it becomes a de facto argument for canceling
or re-chartering the project.
Paradigms of Good Enough
Most businesses practice some form of good enough reasoning about its products.
The only ones that don't are those that believe they have achieved perfection,
because they lack the imagination and skill to see how their products might
be improved.
Here are some good enough models 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,
non-controversial goals. If we meet those goals and 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 is good enough.
Advocacy("we make every reasonable effort")
We advocate for excellence. Throughout the project, we look for ways 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 as would otherwise be possible. 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, it can be said with certainty that we can always spend more time on
much better tests, much more error handling, and fixing or rewriting 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. The problem with that is 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 may be easy. For a complex, high stakes product,
it's very hard.
Further Information
Included in the Unified Process for EDUcation, to aid in your evaluation of product
quality, the following types of information are available for most artifacts:
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.
See also Concepts: Measuring Quality,
Key Concepts:
Artifact Guidelines and Checkpoints for additional information
Overview >
Concepts >
Test Concepts >
Product Quality
