First steps are often the most important, and the first step to improving quality is getting priorities straight. To improve quality in a product and the process by which it is created, quality has to be a priority. If quality is not important to you and to an organization, and it doesn't show in what management actually does and how they do it, quality won't be important to the software development staff. This does not mean posters that declare “Quality Is Job One!” or memos urging employees to strive for zero defects in software. In this area, what counts is how you walk the walk, not how you talk the talk.

Unfortunately, common assumptions and practices of modern managers often prevent them from making quality a real priority. One major hindrance is that many companies are dominated by the issue of time-to-market. Especially in high-technology fields like software development, management vision is limited, transfixed, unable to see beyond the so-called “market window.” If you miss this window of opportunity, so the accepted line of thought goes, all is lost. The idea is to get into the market before anyone else, even if it means shipping a bug-ridden, inferior product. When concern for the market window takes precedence over quality, quality will suffer. It's as simple as that. Timeliness does matter, of course, but it's a matter of priorities. When the choice comes down to packaging and selling what is really a beta-test version now or holding on tight through another round of testing and refinement, which path is followed?

Many software developers continue to let the idea of market window drive their thinking and keep them from producing higher quality systems. Yet the history of our industry is littered with the ghosts of companies that were first in the market and are no more, as well as with innovative but immature products that lost out to later improvements.

Another way that contemporary management thinking works against making quality a priority is that most companies, especially in the United States, seem more concerned with costs and cost-cutting than with return-on-investment. This is all too easy to do when the economy sours and profits are squeezed. Education, training, and staff development, all recognized as important contributors to quality, are considered to be costs, not analyzed as investments. Staff attendance at conferences and seminars may be an essential part of maintaining a competitive edge, but this is regarded as part of overhead expenses and is often among the first targets of cost cutting.

This is not a matter of soft-headed notions of “being nice” to staff, but a question of the financial basis of management thinking and decision making and how this affects the ability to improving quality. If the cost of a six-month delay in announcing and releasing a product will be paid off in another six months, then rushing to market is not a cost savings.

How money is spent ought to be justified, but the analysis should be based not on cost alone, which is only one side of the equation, but on return on investment. Australian consultant Rob Thomsett has shown, for example, that similar gains can be achieved through investing in CASE technology or in team building, but the return on investment with team building is an order of magnitude better. Still, CASE is flashy technology that can be shown to visitors, while effective teamwork is invisible, so many companies would rather spend on hardware and software than on peopleware.

For quality to be a priority, people must be evaluated and rewarded for turning out quality work. But what do we reward? In software development, productivity, whether in function points or lines of code, is usually what gets the bonus or promotion or recognition, if anything. Or we reward herculean, last-ditch efforts to meet seemingly impossible deadlines. Ironically, in many companies it is in the best interests of project managers to ensure that all-out efforts are needed toward the end of a project. Such highly visible commitments are what is most likely to win approval whether the project succeeds or not. “Well, we lost the contract, but no one can fault Pete, who worked around the clock right up to the deadline.”

The problem is not that people don't care about quality, as some managers complain. One study of 11,000 people in six industries (by Brooks International in 1991) found that more than nine out of ten employees felt a personal responsibility for doing quality work. But seven out of ten reported that quality was not an important factor in how their work was evaluated. And a bare one out of four said that their management really rewarded improvements in quality. What do we reward, then? The truth is, recognition and rewards of any kind are a lot less frequent than most managers think. Some 80% of managers claim they give their subordinates sincere and thorough praise, but only one out of seven of their subordinates see it that way (Lickert 1989).

If we want to improve quality, we ought to follow the Ferber Principle. Psychiatrist Andrew Ferber was once asked what was the most important thing for beginning therapists to know if they wanted to help client families improve. His answer:

Nearly everyone has heard the dictum that you can't control what you can't measure (DeMarco 1982). This is often a prelude to a hard sell on starting a software metrics or statistical quality control program. Formal measures have many advantages, but a moment's reflection will tell you that there are many important things in life that parents, teachers, managers, and others control but that they do not measure. Many of these probably cannot be measured. When it comes to people, the essential thing is attention, not measurement; what matters is what you monitor. Any effective parent knows that if you pay attention to tantrums you get more tantrums. Systems in general, and human systems in particular, have the peculiar property that the very act of observation changes what is being observed. This is the basis of the well-established Hawthorne effect: simply making a group the object of study, paying more attention to what they are doing, can lead to improved performance.

What, in particular, you monitor matters, of course, because whatever you monitor is affected. If programmers are evaluated on the tightness of their code, they produce smaller systems; if user friendliness is the criteria, you get friendlier programs (Weinberg and Schulman 1974).

In Australia, the new manager of a maintenance programming group wanted to improve not only the effectiveness of his team, but also its status and recognition in the company. Among other things, he started sending reports back to the original programmers about the bugs discovered and corrected in their systems after they were “in production.” A programmer might get a note simply saying that over the weekend the system had crashed without closing the output file, but that Maintenance Programmer Quinnthorpe had tracked it to a loop in module Z091, which was corrected, recompiled, and tested in 1.6 hours.

An interesting thing happened as the result of this practice. The new systems being put into production got more reliable and started passing acceptance tests more quickly. The mere act of monitoring quality and reporting the results can bring it under control and improve it.

In another company, bar charts were posted every month showing programmer productivity in lines of code written and debugged. After the reports were changed to include all delivered code, not only that written by programmers but also all included modules from the reusable component library, reuse rose dramatically (see Chapter 27).

Feedback is the essential ingredient. When workers have access to information about their performance and its relationship to organizational objectives, quality goes up. This is the basis of the open-book model of management, in which workers are given not only reports about production and defects, but financial information about related costs, revenues, and profits (Case 1990; Finegan 1990). With this kind of information in hand, workers are in a better position to optimize how they spend their time and to improve their own work process. The key is feedback that ties individual and team performance to the larger financial picture, for example, reporting not only programming time and program defects, but the costs of these and the resulting profit (or loss) on a project. Many managers have learned that it's a two-way street. When more information is shared with staff, they share more with management, and a continuous flow of ideas for improvement results. In technical management, we tend to think of measurement mostly in terms of numbers with three-digit precision or better. But qualitative methods and measures or simple rankings may often be enough to evaluate and bring a process under control. The theory of measurement, a part of statistics, recognizes various levels of measurement. Numbers that you can multiply and divide are at one level, a so-called ratio scale, those you can add and subtract at another, lower level, called interval scaling. But even where results can only be quantified enough to say that one thing is better than another by some unknown amount, statistical analyses are possible.

You do not need to measure altitude to the nearest meter to find the lookout tower at the top of the mountain. All you need to know is whether each step is taking you down or up. For many processes, effective strategies for improvement can be based on measurement as crude as just knowing whether you are getting better or worse.

Most managers would probably claim to value information and would like to think that they base their decisions on data. Unfortunately, these same managers often keep themselves from getting the information they need and may be oblivious to some of the information they do have.

The true scientist knows that there is no such thing as an experiment that fails. Whatever happens yields information that can lead to revising the hypothesis or refining the technique. In family therapy training I learned that whatever happens in a session is informative, or, as we used to tell our trainees:

The true manager knows that all news is good news. Information about a process has intrinsic value and should be valued. How you react to information affects how accessible it will be in the future. Where one side is rewarded, the truth will not be known. The problem with punishing the bearer of bad news is not only that it's hell on messengers but eventually it assures that only good news will reach you. The “bad” news, which is often the most critical to know about, isn't delivered.

I once had a boss who told me that he would never hold it against me for keeping him informed of problems, that he particularly wanted to be kept apprised of difficulties that might jeopardize the agency we both worked for. He not only kept his word, but also left the resolution of such problems to me and my staff. This helped keep the lines of communication open and insured that he had access to information critical to his decision making.

In improving any process, the most important information to know, of course, is about problems and failures, yet this is precisely the information that managers may be warding off. Finding a bug in a program ought to be the occasion for a celebration. In fact, all program faults should be not only recorded, but also studied.

Keeping detailed logs of all problems—defects and mistakes, customer complaints, design changes, analysis errors, “improvements” in beta testing—is one essential step. The other is to study these systematically and periodically. This means setting aside as part of every project the time for systematic reflection. If we don't study and learn from our mistakes, how can we avoid them in the future?

To improve quality, it is especially important that we never confuse opposition or criticism with disloyalty.

It is often the contrary view or the critical perspective that offers the most information about potential improvements to the process. In fact, the quality of problem solving is critically dependent on critical input. Groups that include a “resident critic” or “devil's advocate,” or that exploit dialectical processes of opposing ideas and active critique, perform better (Constantine 1989; Priem and Price 1991).

Of course, it is not simply enough to know that something is wrong or even how it is going wrong; we have to do something about it. Program bugs are not just information about something wrong in specific programs; they are also information about problems in the process that generated the programs. The first question is how did it get there? The goal is not to fix blame, but to learn how to change the process so that it is less likely to happen in the future. Organizations that continually improve their processes take each failure as an occasion to retrain or to refine the process and improve it.

A powerful principle of quality improvement is found in the title of a hit song from the 1960s:

Invisibility is the enemy of quality. We can't improve what we don't see. One of the best ways to assure that somebody sees a problem is to make what software developers are doing more visible.

Experience has shown that the quality of software can be markedly improved simply by increasing the amount of work that is done face-to-face (Chapter 26). When two or more people work together on the same problem, quality goes up. On the average, increasing the visibility of work increases quality. Why? Basically, in order for two programmers cutting code together to introduce a bug or a departure from standards and practices, they have to collude; to find the bug or spot the departure, only one has to see it. Forget about what you've heard about “groupthink” or collective mediocrity. It turns out that such effects exist but depend on special conditions. Group leaders can do simple things that go a long way toward improving the quality of problem solving and avoiding groupthink. Simply by delaying or withholding their own opinions, group leaders can significantly improve the problem solving of any group (Anderson and Balzer 1991).

The “two-to-a-terminal” model of programming, which I have called the “Dynamic Duo,” dates from the era that introduced “ego-less programming.” Ego-less programming was based on the notion that programmers had too much ego invested in their code. If only they could work in an ego-less style, becoming less defensive and more open to the review, suggestions, and criticisms of others, they would produce better code. There were a number of problems with this way of thinking, not the least of which is that people have egos. Modern management thinking, rather than trying to stamp out or overcome egos, seeks to take this reality of human nature into account and turn it to the collective good.

The watchword today is “ownership” or “buy-in.” Progressive organizations seek to increase the sense of personal ownership—ego investment, if you will—that employees have in the products of their efforts. For example, the structured open model for teamwork (see Chapter 16) is an approach to organizing project teams that uses consensus-based problem solving to increase work visibility and individual ownership.

An essential variant on the theme of work visibility is the idea of separation of powers. It's implicit in the Dynamic Duo approach to programming. While one programmer is at the keyboard, the other is looking over his shoulder. The programmer at the keyboard has one set of responsibilities associated with defining the algorithm and mapping out the flow in code. The other is looking for the holes in the logic, trying to spot weaknesses or errors.

This principle is an essential component of “cleanroom” programming, an approach that has produced some moderate to large-scale systems demonstrated to be virtually bug-free (Cobb and Mills 1990). In this model, one person or group writes the code, trying to “get it right.” But someone else compiles and tests it, trying to find what is wrong with it. There is more to the model, but simply this kind of separation of responsibilities in itself seems to improve quality. Knowing that someone else on the team is not only going to see the code, but take over compiling and testing, seems to lead to greater care and more effort to get it right the first time.

Decades of research and practical experience has taught us that often more than an order of magnitude in productivity separates the best programmers from the worst, and the best are typically twice as productive as the average ones (DeMarco and Lister 1987). Some groups have dramatically improved quality and productivity by the simple expedient of cutting their programming staff, keeping only the best half. One approach to quality is to take only the very best players, give them all the resources and motivation they need to do the best job, and let them do it. This may be especially appealing in an era of “downsizing.”

Of course, every manager knows that there are “stars” in any organization, but not everyone wants to get rid of all the supporting players. What we'd really like to do is find a way to help the others “get better.” Which brings us to the principle of cross-training. The idea is to create more opportunities for software development people to learn from each other.

One of the most effective and efficient ways to accomplish this cross-training is to build it into the way projects are organized. This goes back to work visibility. By doing more of their work in face-to-face groups, team members automatically learn more from each other. In addition, rotating responsibilities as a normal part of software development gives opportunities to practice, helping to gradually disperse skills and knowledge through the group.

Differences in natural talent and achievable levels of skill will always persist. Some programmers will always be better at cutting clever code, some better at modeling essential abstractions; one team member might always be a better group facilitator than the others. But in an organization that encourages and makes room for cross-training and skill dispersion, the average level of skill in any of these areas is always increasing. Over time, people will pick up more and more of each other's specialties. They will never reach the point where everyone can do all the jobs with equal skill, but the differences will diminish. Most importantly, team members become increasingly able to fill in for each other. The organization as a whole becomes less critically dependent on the skills and presence of any one member. An entire project need not then become stalled simply because one person becomes ill or takes a job in another city.

Ironically, in many organizations that sincerely want to improve quality, common practices create conditions preventing improvement. Things as simple as how deadlines and budgets are established can make or break a project in terms of quality. In the typical situation, all factors—budget, allocation of resources, staffing, methodology, and deadline—are fixed when the project is given to software developers. Where can we get improved quality? We need at least one degree of freedom. If all the variables are constrained, the system is over-determined and there is no way to win. So what is sacrificed when there are problems? Quality! Under tight deadlines, such as those driven by some imagined market window, it often comes down to, “We don't have time to do it right.” This points to one of the simplest changes that has been found to help improve the quality of software.

Software developers need to be directly involved in establishing delivery dates and project deadlines. Setting a completion target should be approached as a negotiation in which there are recognized trade-offs. “Yes, the project can be delivered by the end of the year if you don't mind having a defect rate around 15 per KLOC. Or we can promise a lower defect rate if you don't mind cutting out half the screens.”

Approaches to raising software quality do not have to be complicated or involve large budgets. Some simple things can make a big difference. First, get your priorities straight, make quality a priority. Don't let the market window run your business. Think in terms of return-on-investment, not cost containment.

Then, pay attention, recognize and reward quality. Give feedback, and be generous with information. Keep listening: remember that all news is good news, especially bad news. Encourage critical feedback. Record and study defects, and correct the process, not just the program. Let the sun shine in; make work more visible. Promote cross-training: let each one teach one. When quality is especially essential, use only the finest ingredients. And always negotiate your deadlines!

Revised from American Programmer, February 1992.