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