J. SYSTEMS SOFTWARE 83 1991: 16:83-X4

Editor’s Corner Robert L. Glass

Quality Software: What is Management’s Role?

Perhaps you’ve already discovered that marvelous book, Peopleware, by Tom DeMarco and Tim Lister (Dorset

House, 1987). If you haven’t, you should. It’s the first “breath-of-fresh-air” book on the computing scene

since Fred Brooks’ The Mythical Man-Month came

out over a decade ago.

Why is it a breath of fresh air? Because DeMarco and Lister write from the point of view of those who

do software, not those who contemplate software. There’s a big difference.

Let me give you an example. There’s lots written on the problem of building quality software products. Most

people see the achievement of quality as a management topic. DeMarco and Lister skewer that point of view in

Peopleware. First of all, they say, the self-esteem of individual workers is tied strongly to the quality of the product they produce. Not the quantity, the quality.

Secondly, they say, “There is nothing more discourag-

ing to any worker than the sense that his own motiva- tion is inadequate and has to be ‘supplemented’ by that

of the boss.”

Now, think for a minute about what kind of advice people give on how to manage quality into software

(and other) products. We see motivational cam- paigns-big placards shouting things like “Zero de- fects” or “Think quality” at the workers, as if by reminding them often enough we will manage them into

not forgetting to put quality into their products. But that’s all wrong, say DeMarco and Lister. The natural

tendency of the employee is to put quality in. By trying to motivate workers to do it better, we simply alienate them. If management tells you to do something better

that you’re already doing to the best of your ability, what will your reaction be?

A better approach to quality, they say, is to

l get the right people

. make them happy so they won’t want to leave

. turn them loose

This editorial was reprinted with permission from the column “Software Reflections” by Robert L. Glass in Sysrem Develop- ment, P.O. Box 9280. Phoenix, AZ 85068.

0 Elsevier Science Publishing Co., Inc.

655 Avenue of the Americas. New York. NY 10010

In other words, the right way to manage software quality into the product is to get out of the way and let the workers’ natural tendency toward quality come into play. In fact, the real quality problem, as DeMarco and

Lister point out, is that the software builders will put

too much quality into the product! Their individual standards are “invariably a higher standard than what

the market requires and is willing to pay for.”

So what kind of sense does it make, they ask, that “those same folks who are chided for being inclined to ‘tinker forever’ with a program. . are also getting blamed for poor quality”? “Let’s put the blame where it belongs,” they go on to say. “By regularly putting the development process under extreme time pressure and then accepting poor-quality products, the software user community has shown its true quality standard.”

It’s all part of a generic problem. Over the years, somehow, software quality has become a management issue rather than a technical one. And we’ve institution-

alized that concern into an organization called “Quality Assurance. ’ ’ The task of quality assurance is somehow

to make sure, on behalf of management, that those

technical people are doing a good, quality job. In many ways, there’s foolishness in that approach.

There’s foolishness, as we’ve already seen, because those technical people are likely already doing the highest-quality job they know how to do. But there’s

another reason there’s foolishness here. Think for a moment about what quality is. The most

common definition is that quality is a set of attributes,

things like portability, and reliability, and efficiency, and human engineering, and understandability, and

modifiability, and testability. Now picture yourself, as a software manager, trying to determine whether the software your people are producing has the quality attribute of modifiability, for example. How would you go about seeing if the software was modifiable?

The answer is, you would employ a technologist to find out. It is simply not possible for a nontechnical person to evaluate the modifiability of a software prod- uct, because doing so requires an ability to read and understand code, and make a judgement about how

easily that code can be changed. The same is true to a greater or lesser extent for all of the quality attributes.

0161.1212191 i3.50

84 J. SYSTEMS SOFTWARE 1991; 16:83-84

Determining the presence or absence of quality is a technical task, not a management one.

And all of that says that, whatever we call our

“quality assurance” function, it has to be either well staffed with doers who can evaluate quality at its most

intimate level, or it has to establish a process by which the doers can make that evaluation.

Now, all of this isn’t to say that quality assurance, and management, have no role in the achievement of

building quality software. Management must take re- sponsibility for the quality of the technical product their people produce, and there must be a checks and bal-

Editor’s Corner

antes system (like quality assurance) that helps man- agement know whether those technical people really are

doing that quality job. But it does say that what we’ve been doing until now

has been all wrong. Well-motivated, well-supported technical people are the best route to software product

quality. The role of management-and of quality assur- ance-should be to facilitate this. Instead of what De- Marco and Lister call a “quality-if-time-permits” cul- ture, we need what they call a “cult of quality. ”

Think about how you might achieve that in your own

organization. And read Peopleware!