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 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.
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 work products included in the RUP:
-
Work Product Guidelines and Checklists: information on how to develop, evaluate, and use the work
product.
-
Templates: "models" or prototypes of the work product, providing structure and guidance for content.
For additional information see Concept: Measuring Quality and Concept: Artifact, Artifact Guidelines, and Checkpoints.
|