J, SYSTEMS SOFTWARE 203 1992; 17:203-204

Editor’s Corner The Importance of Software Quality in the 1990s

Robert L. Glass

The 1980s was the decade of software productivity. I

am one of those who believes that the decade was a

dud. We tried and tried to achieve major breakthroughs in productivity, and even claimed we had a few times,

but when the smoke cleared what we had was some

nice, tidy improvements, but no breakthroughs. There are those who now say that the 1990s will be

the decade of software quality. Will we indeed predict

quality breakthroughs as the decade proceeds? Will we achieve them? To lay the groundwork for a decade-long

probing of those questions, let’s look at the broad topic of software quality in the early 1990s.

Computers and software have permeated every part of people’s lives. They direct our appliances, facilitate

and control our travel, handle our finances, and make more convenient the necessities and non-necessities of

life. Without computers and software, our society would probably come slowly to a halt.

With that as a given, the ante for software quality is enormous. Poor quality software could inconvenience us; it could entangle society; it could kill people. Is that an exaggeration?

Picture some very large software. TWA’s computer-

ized reservation system, when it was first developed, was flawed. A high-priority quality program, under-

taken at considerable cost, saved the company $1.75

miltion once it was completed. They bet the corporate coffers on software quality.

Picture some very widely-used software. Microso~ had to recall a product a few years ago because of some serious bugs it contained. We are talking here about thousands, even hundreds of thousands, of customers who were inconvenienced because of software quality. But more to the point, Microsoft had alienated a large part of its customer base. Quickly, they formed a quality organization to monitor product quality. They

This editorial was reprinted wiih permission from the coi~m~ YSoftware Resection” by Robert L. Glass in System Develop- ment, P.O. Box 9280, Phoenix, AZ 85068.

0 Elsevier Science Publishing Co., Inc. 65.5 Avenue of the Americas, New York, NY 10010

couldn’t afford to make that mistake again; they bet their company on every software product.

Picture some software produced by a careless person. Some day soon a software producing company -and its programmer-are going to get sued for mal-

practice. It happens to doctors and other profession~s now. Software people soon will be betting their finan- cial future on every line of software they write.

Picture some software produced by a usually careful person. In early 1990, AT&T’s telephone system suf-

fered what Business Week called “nine hours of

chaos” because some special software to help the sys- tem be fail-safe was itself flawed and took the system

down with it.

Picture some life-critical software. Computers and software control the newer aircraft. Those computers

and that software are capable of taking off and landing

an airplane without a pilot on board. You literally bet your life on software when you ride on one of those

airplanes. When an Airbus A320 crashed at the Paris air show in 1988, the press initially assumed the flight control computer hardware and software were at fault

(the real reason was discovered later to be “pilot

error”). For the most part, software quality was a much less

visible thing a few years ago. Software applications

were smaller then, they were less critical, they were less pervasive. All that, in this rapidly growing field, has changed. Most of us, excited by the promise of the

future, are glad for that growth and change. But the dimension of the change is almost overwhelming. Now, when we consider software quality:

l huge amounts of money are at stake;

l corporate success or failure is at stake;

l the personal future of software people is at stake;

l lives are at stake.

Software quality is no longer an option, an add-on whose cost we may debate and consider doing without. Software quality is a requirement.

204 J. SYSTEMS SOFTWARE 1992; 17:203-204

Editor’s Corner

What are the biggest concerns in software quality? Probably the greatest one is poor schedule estimation. Typically optimistic, perhaps prodded by political con- siderations, software managers badly underestimate the schedule aspects of completing a software project. Then pressure is placed on the software technologists during testing to achieve that unreasonable target. The result is poorly tested software.

What is the second biggest concern? The softness of software means that it is malleable; change is a big part of the competitive advantage of solving problems in software. But this results in unstable requirements dur- ing software development, as customers with increasing vision of the final software solution change their needs as the project evolves. The result is that software developers are shooting at a moving target. A never- completed software solution, or a correct solution to an

obsolete problem, is no better than an incorrect solution to a well-understood problem.

Unfortunately, there is little data on the frequency of software quality problems. Some say there is a “soft- ware crisis” in which &‘software is always over bud- get, behind schedule, and unreliable.” But I would assert that that is largely untrue. The dramatic success of software solutions far overshadows the quality prob- lems of software as we enter the 1990s. There are problems, but they are not ubiquitous.

so . . . whither software quality? The groundwork is laid for potential progress in software quality in the 1990s. The need is certainly there. The motivation appears to be there. The question now is, “what can we achieve?” Like everyone else, I am eagerly await- ing the answer.