Quality Ought To Hurt

It’s been seven years since the public cared about software quality. It’s been seven years since CEOs and CFOs, Joe Six-Pack and soccer moms, presidents and kings gave a moment’s thought to bugs and flaws.

Seven years ago, remember, companies large and small were obsessed with the Year 2000 bug. Congress and the United Nations held hearings about it. The New York Times, Washington Post and Bangor Daily News ran stories about it. The Frankfurter Allgemeine, China People’s Daily, O Estado de S.Paula, and Vancouver Business Journal did, too.

Within our industry, thousands of technical articles discussed best practices for swatting the Y2K bug. IBM and PriceWaterhouseCoopersLybrandEtc. mobilized armies of pinstriped consultants. Consumers panicked. Governments panicked. Companies, frightened about lawsuits, paid beaucoup bucks to recruit old COBOL and RPG programmers.

Why was Y2K such a big deal? Because the consequences were made tangible.

Riders would get stuck in elevators, we were told. Weapons systems would shut down. Airplanes would crash. People would die. Worse, businesses would get sued. Or so everyone thought — and this scared them into making a huge, if one-time, investment in software quality.

Y2K came and went, and airplanes didn’t crash. Whether that’s because the bugs were bogus, or because those armies of consultants actually found and fixed flaws, I don’t know. But the truth remains: Governments, the media and consumers cared about software quality because the consequences were made real in terms of lives and dollars.

Software quality can’t be an abstract concept. Think about engineering, where there’s a tremendous commitment to quality: If a bridge isn’t architected properly, it falls down and people die. If an anti-lock brake system has bugs, cars crash and people die. A software flaw in the first Ariane 5 rocket, launched in 1996, caused the loss of a $500 million satellite.

Stories like those get people’s attention, if just for a little while.

The U.S. government understands that the only way to get companies to do things is to enact real and severe penalties. You’ve probably heard the capsule summary of Sarbanes-Oxley: “Do it right or the CEO goes to jail.” The threat of going to jail gets people’s attention, too, if just for a little while. That’s why we’re going to need some SarbOx perp walks to keep this issue in the public eye.

So, what does I.B. Phoolen recommend? Among other things, more visibility for software quality. Lots more visibility. Think about how the U.S. National Transportation Safety Board maintains an extensive database of aircraft accidents and near-accidents. This database, and the NTSB incident investigations, not only catch design flaws and defective aviation hardware/software, but also point to where aircraft operators, airports and maintenance crews don’t follow proscribed operating procedures.

“Best practices,” you know, ain’t optional in the aerospace industry. Why are they in the software industry? What if companies were forced to divulge all software flaws publicly to a National Software Safety Board, and submit to external investigations? You can bet they’d pay a lot more attention to quality. If that NSSB could mandate software recalls, the way automobile and aircraft manufacturers can be forced to repair — at their own cost — product defects, wouldn’t we all be better off? What if Microsoft had to file a government incident report every time someone found a Windows bug?

Transparency is a good start, but I.B. says that it’s not enough: Bugs ought to hurt, not just in the company’s cost to fix the bug, but in significant damages and penalties. I’m talking big fines. Didn’t check that buffer? $1,000 per buffer per user. Web site’s vulnerable to SQL injection? $50,000 per input field. Shipped products with known flaws? Didn’t catch an exception? Failed to certify the printer driver? $10,000 for each end user, thank you very much. Ka-ching!

Penalties like those get people’s attention, and not just for a little while.

Today, software quality for both enterprise and commercial software is left almost entirely up to the software maker to decide and address. Customers’ legal rights are often entirely abrogated by shrink-wrap software licenses and the fine print in Web site legal statements. If a bug in a commercial operating system or application costs you time and money, wipes out your data or shuts down your business — tough luck, kiddo, trying to recover anything in court. (With open-source software, at least you can try to spot flaws and fix them yourself.)

We insist on transparency and penalties when it comes to cars, aerospace and civil engineering. We should demand that for software, too. The only way to force ISVs — and those allocating resources to enterprise software development and QA teams — to be serious about quality is through bad publicity, nasty fines and criminal penalties for violations. Didn’t check your return value to detect a null pointer? Buddy, tell it to the judge, tell it to the judge.