March 2002
Volume 4 • Number 2

Contents

From the Editor

One sign of the maturing of our profession would be a wider acceptance of the concept of “software malpractice.”

Doesn’t malpractice (literally, bad practice) imply a contrasting expectation of good practice? Such good practice produces software-based systems that are fit for use, that satisfy stakeholders, and even delight users. Our professional efforts of research, training, certification, and communication—including this journal—are directed at establishing and disseminating good practice. Why tolerate behavior that is clearly contrary to our most rudimentary understanding of what is proper?

Other established professions have what is known as a “standard of care” or “due diligence,” or some other measure against which competence is judged. Granted, a surgeon must remove the wrong organ or a lawyer accept a bribe to be seen as beyond the pale, but there are limits and there are sanctions for clearly unacceptable performance.

Yet how often do we see the magnitude of corrective software maintenance and realize that consumers wouldn’t tolerate such imperfection in tangible goods or well-defined services? Is it because of a culture of technically “sweet” solutions, whose imperfections are tolerated because of the “gee whiz” nature of the technology?

“I’m sorry, but our system is down right now” may no longer be an acceptable excuse for lack of service. If a company has computerized its processes, shouldn’t the new system be at least as reliable as the old one? The rule when I first worked on computerizing power-plant control and safety systems was that the reliability of the new digital system must be demonstrably greater (in one particular application, an order-of-magnitude better) than the analog system being replaced.

Yet many firms don’t even seem to have a manual backup alternative to the computerized system. It’s as if they threw away their pencils and paper when the computer screens were added.

This ineptitude may provoke a case of “bottom up” demand for professionalism. There are ongoing “top down” efforts to define standards, and I wholeheartedly support the ASQ Certified Software Quality Engineer as well as the emerging Professional Software Engineer designation. Yet the real leverage may come from the impatience of the consumer.

I have joked that much of life can be explained by an appropriate two-by-two matrix. In the marketplace, that matrix would have one dimension for demand (“many want” or “few want”) and the other for supply (“many can provide” or “few can provide”). I sometimes feel my specialization puts me in the quadrant where “few can provide” but also “few want.” Of course the ideal quadrant is to be where “few can provide” and “many want.”

Unfortunately, it seems the software industry can be characterized by “many want” but also “(too) many can provide.” It’s easy to develop software, and hard to know when it has been done well. It’s easy to test software, and hard to understand what the testing means. It’s easy to assess the quality of software, and hard to evaluate the adequacy of that assessment.

We are right to aspire to excellence—to emulate the quality award winners and to learn from the level 5 outfits. (See “Use of Metrics in High Maturity Organizations” in this issue.) However, we must also be attentive to the other end of the spectrum.

There are some individuals and some organizations that are creating negative quality, and are not only disappointing their employers and their customers but also, perhaps more important, bringing into disrepute our profession.

Technically, it is improper to advertise oneself as an “engineer” without holding a license as a professional engineer. The real harm is in the representation to the wider public that one possesses the knowledge, skills, experience, and commitment that should be expected from an engineer. Incompetents claiming to be engineers may lower the esteem in which the profession is held. Unchecked, they may also perpetuate bad practice, which could be costly or harmful to the public.

Why shouldn’t those of us who take seriously our title of software engineer, quality engineer, or software quality engineer work to guard that title more jealously? Why shouldn’t we be working for both legal and popular recognition that our engineering practices are as fully professional as other established disciplines?

If you have read this far, it is a sign of some interest on your part. Perhaps that interest might even be translated into concrete action. I would be delighted to hear your ideas for upholding the standards of conduct appropriate for software quality professionals. Perhaps that will begin by throwing out some of the incompetents, by calling unacceptable behavior what it is—malpractice.

Taz

sqpeditor@aol.com

back to top