InformationWeek

Worse still, it was a defect known to the system manufacturers, who chose to do nothing about it. Instead, it appears that they made things worse by providing the pilots with a defective interface design that only exacerbated the problem.

A tale of fiction? I wish; but no. Sadly, it's another chapter in the long and inglorious saga of poor-quality products, shortsighted thinking, and ethically bankrupt behavior that we've come to accept as business-as-usual in the software industry. It's time we quit spending good money on bad code.

Software makers often bandy about delusional myths like "software is art" and "quality takes longer." Actually, the design and construction of buildings, like the design and construction of software, also has an important artistic side, meaningful differences notwithstanding. But the work of building architects and artisans is grounded in the discipline of science and engineering. There's no good reason the same kinds of discipline can't be applied to the work of software architects and artisans. In fact, it's being done already.

The evidence is also clear that good software-quality practices reduce costs and time to market. This is true even when the costs to customers aren't considered--as was apparently the situation that led to those 159 deaths, blood on the hands of the participating software designers and programmers, and a $75 million liability suit against their employers.

After nearly three decades at IBM leading software development and later quality assurance, Watts Humphrey joined the then-fledgling Software Engineering Institute (www.sei.cmu.edu) and in 1987 gave us the Capability Maturity Model. CMM is a five-level model for assessing and improving the maturity of an organization's software processes and practices. Users of its approaches have seen enormous reductions in defect rates and the costs of software quality, as well as increased profits.

Curiously, just as U.S. companies largely ignored manufacturing-quality gurus W.E. Deming and J.M. Duran, while they were embraced overseas, the pattern is similar with the software quality teachings of Humphrey and the institute. A recent list of companies that have reached CMM's level five shows that 21 of the 36 are in India.

A deeper inspection indicates that at least 10 of the 15 U.S. level-five software shops focus on military, space, or aerospace applications--and none of the rest appear to be particularly concerned with business, transaction, operating, or desktop systems, except perhaps Lockheed Martin Federal Systems. It's noteworthy, however, that Citicorp, Computer Sciences, IBM Global Services, and Perot Systems own CMM level-five shops in India.

The implications are clear. Just as U.S. manufacturing pre-eminence and market share was toppled by those who embraced good quality practices, the same thing may happen with the software industry. The bodies won't bleed like those unfortunate 159, but the ink could run red for U.S. software makers, while profits, market share, and jobs move to other countries.

So what can you do to improve software quality? Some suggestions include: