When there is a quality problem with our products, where do we look to solve it? If we look to quality assurance, we will be disappointed. QA can measure the problem, and maybe even identify possible causes, but they cannot add quality to our products.
Quality must be built into our products; it can never be tested in after the fact. Although QA has an important role in assuring the quality of our products, their work is entirely indirect. Their role is to influence others in the organization. It is those other people who will build quality into our products. (Or not.)
The primary responsibility for quality lies with management, beginning with the highest executive ranks, and continuing all the way to first line supervisors. It is management who establish priorities, set the tone, define the culture, and show the employees what is "important". All of the members of the organization will follow management's lead. Even if they wish that management would change their priorities, people will still align themselves with management's actions.
So, how should management act in order to foster an environment in which high-quality software is built? The first thing they must do is to ask about quality. Don't ask about schedule without also asking about quality. Don't be concerned about budget variance without also asking about quality variance. Don't set cost objectives without also setting quality objectives.
Of course we will not be able to ask about our organization's quality performance until we understand our historical quality performance and establish targets for our projects. And we will be unable to ask pertinent questions about quality until we achieve a working understanding of the metrics that will provide the perspectives we need.
In short, if we are to lead our organizations toward achieving better quality results, we must educate ourselves about quality. Just as we have established a good understanding of how to manage budgets and schedules, we need to learn how to manage quality. We need to familiarize ourselves with the costs and the benefits of each quality-related activity our projects may employ so we can invest in the activities that will pay dividends, improving our quality performance without negative budget and schedule implications.
Management's role is to educate ourselves so we can make wise investments in quality, and ask our staff questions that will guide them to value good quality performance.
Second only to management is the programming staff's responsibility for quality. The quality of a system is just like any other attribute or feature; it will not be a part of the system unless those who build the system build it in. Quality cannot be tested into a system, just as knowledge cannot be tested into a student. The quality of a system is the net result of the care with which all of the engineering activities have been undertaken.
So, how should the programmers act in order to improve the quality of the systems they build? Their first step in improving their performance (along any dimension, be it quality, productivity, or technical skill) is to understand their current performance. Each engineer should measure the quality of the programs he builds, and gain a functional understanding of his capacity to produce consistently high-quality products.
Just as every pitcher knows his Earned Run Average, every runner knows her average and best times for each race, and every running back knows his average yards per carry, each programmer should know her average defect density, productivity, and defect injection rates for design and coding activities. Armed with these statistics, the programmer (like the athlete) has a basis for setting improvement goals and altering behavior in order to make progress toward them.
And just as teams employ coaches to guide athletes in improving their performance, so also programmers need the guidance of knowledgeable individuals to help them to set