Return to Bad Software: What To Do When Software Fails.


Lawsuits, Lawyers, and Quality-Related Costs

This article was originally published as "Software Quality & the Law" in The Gate, the newsletter of the San Francisco Section of the American Society for Quality Control, July, 1995, p. 1.


Copyright © Cem Kaner, 1995. All rights reserved.


In his book, Out of the Crisis, W.E. Deming listed Excessive costs of liability, swelled by lawyers that work on contingency fees as one of the seven Deadly Diseases. I'm a CQE who recently became a lawyer. My objective is to use the legal system as a vehicle to improve software quality, either as a corporate counsel who works with Engineering in a proactive manner, or as a plaintiff's attorney who files expensive bug reports on a contingent fee basis. In my view, litigation over defective products puts pressure on companies who don't care about their customers. It empowers quality engineers. It is part of the cure, not one of the diseases.

Software quality is often abysmally low. It is impossible to fully test a software product, so all software is necessarily shipped with defects. (For a discussion of the problems of testing, and of the types of defects in software, see my book, Testing Computer Software, 2nd Ed., with Jack Falk & Hung Quoc Nguyen, Van Nostrand Reinhold, 1993.) Many companies ship software with significant, known defects. Others don't test the products well enough to discover the most serious problems.

As Quality Engineers, we study quality-related decision making from a financial viewpoint. Our objective is to minimize the cost of quality associated with each product. (See Principles of Quality Costs, 2nd Ed., Edited by Jack Campanella, ASQC Quality Press, 1990). Figure 1 provides some representative quality costs associated with the development of software products that will be sold to the public.



Figure 1. Examples of Quality Costs Associated with Software Products.




  • Staff training
  • Requirements analysis
  • Early prototyping
  • Fault-tolerant design
  • Defensive programming
  • Usability analysis
  • Clear specification
  • Accurate documentation

  • Design review
  • Code inspection
  • Glass box testing
  • Black box testing
  • Training testers
  • Beta testing
  • Test automation
  • Usability testing

Internal Failure

External Failure

  • Bug fixes
  • Regression testing
  • Wasted in-house user time
  • Wasted tester time
  • Wasted writer time
  • Wasted marketer time
  • Wasted advertisements
  • Direct cost of late shipment
  • Opportunity cost of late shipment

  • Technical support calls
  • Preparation of support answer books
  • Refunds and replacement with updated product
  • Lost sales
  • PR work to soften drafts of harsh reviews
  • Lost customer goodwill

Unfortunately, the ASQC's Quality Costs Committee omitted an important class of quality-related costs when they published Principles of Quality Costs. Look at Appendix B, the Detailed Description of Quality Cost Elements, and you'll see that all of the costs listed are costs borne by the manufacturer / seller of the product.

The manufacturer and seller are definitely not the only people who suffer quality-related costs. The customer suffers quality-related costs too. If a manufacturer sells a bad product, the customer faces significant expenses in dealing with that bad product.

Figure 2 lists some of the external failure costs that are borne by customers, rather than by the company.


Figure 2. Examples of External Failure Costs Borne by the Buyer and the Seller


Seller: external failure costs

Customer: failure costs

These are the types of costs absorbed by the seller that releases a defective product.

These are the types of costs absorbed by the customer who buys a defective product.

  • Technical support calls
  • Preparation of support answer books
  • Refunds
  • Replacement with updated product
  • PR work to soften drafts of harsh reviews
  • Lost customer goodwill

  • Costs imposed by law

  • Wasted time
  • Lost data
  • Lost business
  • Embarrassment
  • Frustrated employees quit
  • Failure of demos to customers and other tasks that could only be done once
  • Cost of replacing product
  • Cost of reconfiguring the system
  • Cost of recovery software
  • Cost of tech support
  • Injury / death

Many of the external failure costs, such as goodwill, are difficult to quantify, and many companies therefore ignore them when calculating their cost-benefit tradeoffs. Other external failure costs can be reduced (e.g. by providing cheaper, lower-quality, post-sale support, or by charging customers for support) without increasing customer satisfaction. By ignoring the costs to our customers of bad products, quality engineers encourage quality-related decision-making that victimizes our customers, rather than delighting them.

The point of quality-related litigation is to transfer some of the costs borne by a cheated or injured customer back to the maker or seller of the defective product. The effect of this is to put pressure on the manufacturer to develop higher quality, safer products.

It is fashionable for companies to whine about their customers' ability to sue over defective products. It's not surprising to hear this -- we've all known executives who care more about this quarter's profits than about their longer term relationships with customers. And we've all heard them whine about those dratted nitpickers in QA. But it amazes me when I hear anger toward plaintiffs' lawyers at ASQC meetings -- fundamentally, we are on the same side.



Cem Kaner consults on technical and management issues, practices law, and teaches within the software development community. His book, Testing Computer Software, received the Award of Excellence in the Society for Technical Communication's 1993 Northern California Technical Publications Competition. He has managed every aspect of software development, including software development projects, software testing groups and user documentation groups. He has also worked as a programmer, a human factors analyst / UI designer, a salesperson, a technical writer, an associate in an organization development consulting firm, and as an attorney (typically representing customers and software development service providers). He has also served pro bono as a Deputy District Attorney, as an investigator/mediator for Santa Clara County's Consumer Affairs Department, as an Examiner for the California Quality Awards. He holds a B.A. (Math, Philosophy, 1974), a J.D. (1993), and a Ph.D. (Experimental Psychology, 1984) and is Certified in Quality Engineering by the American Society for Quality Control. He teaches at UC Berkeley Extension, and by private arrangement, on software testing and on the law of software quality.

Return to Bad Software: What To Do When Software Fails.

The articles at this web site are not legal advice. They do not establish a lawyer/client relationship between me and you. I took care to ensure that they were well researched at the time that I wrote them, but the law changes quickly. By the time you read this material, it may be out of date. Also, the laws of the different States are not the same. These discussions might not apply to your circumstances. Please do not take legal action on the basis of what you read here, without consulting your own attorney.
Questions or problems regarding this web site should be directed to Cem Kaner,
Last modified: Monday November 10, 1997. Copyright © 1997, Cem Kaner. All rights reserved.