Everyone takes quality seriously and wants to produce high-quality products. However, there’s no universal definition of what "quality" means in software. Debates rage about "good enough" software versus more traditional views of software quality. To help steer your group toward success, spend some time working with your team members and your customers to understand what quality means to them.

These two communities often don’t have the same definition in mind, so it’s easy to work at cross-purposes. A manager focused on the delivery schedule might be impatient with an engineer who wants to formally inspect every line of code. A customer to whom reliability is paramount won’t be happy with a product containing scads of seldom used features, along with scads of defects. A spiffy new user interface might turn-off a user whose fingers have memorized how to efficiently use the previous product version.

Note

Assuming that your concept of quality for the product is the same as the quality perspective the customers have in mind.

To better understand our customers’ views of software quality, my group at Kodak once invited our customers—who were fellow employees—and their managers to an open forum to discuss this topic. This forum was valuable because it showed where our group’s ideas of what constituted quality did not match the perceptions of those who used our products. Understanding the differences can help you focus energy where it will yield the greatest customer benefit, not just where it will provide the greatest developer satisfaction.

Traditional interpretations of software quality include conformance to specifications, satisfying customer needs, the absence of defects, and providing value to some person. The buzzword of "six-sigma quality" sets a very high bar for defect density or frequency of failure, but it doesn’t address such quality dimensions as rapid product delivery, usability, a rich feature set, and delivering value for the price paid. While we all would love to have all of these quality characteristics maximized in the products we create and use, trade-offs are always necessary.

During the requirements phase on one project, we listed 10 quality attributes (such as efficiency, interoperability, correctness, and ease of learning) we thought would be important to the users. We asked a group of key customer representatives to rate each of these attributes on a scale of 1 to 5 for desirability. Once we had determined which attributes were most significant, we could design the application to achieve those objectives. If you don’t go to the trouble of learning what quality means to your customers and then designing to deliver that quality, you’re just lucky if the customers get the quality characteristics they expect.

One of the more pragmatic definitions of quality I’ve heard is "The customer comes back, but the product does not." Work with your customers and developers to define appropriate quality goals for each product. Once determined, make achieving these quality objectives an unambiguous top priority. Lead by example, setting high personal standards for the quality of your own work. Adopt this motto: "Strive for perfection; settle for excellence."