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

Cem Kaner, Ph.D., J.D. Florida Tech, Dept of Computer Sciense
Law Office of Cem Kaner  150 West University Blvd., 321-6988  408-244-7000 




Copyright © 1999, Cem Kaner

In Press--Software Quality Professional

The Uniform Computer Information Transactions Act (UCITA) is a proposed new law that will govern all transactions in software, including contracts for sale, licensing, documentation, maintenance and support of computer software. It will also govern contracts involving electronic information (movies, music, text that you download or buy on a CD) and, at the vendor's option, can govern sales of computers and some other devices that are sold in conjunction with software.

Until recently, UCITA was proposed as an amendment to the Uniform Commercial Code, and was called Article 2B. However, the American Law Institute (ALI), one of the two organizations that must approve all changes to the UCC, recently withdrew from the Article 2B project. The other organization, the National Conference of Commissioners on Uniform State Laws (NCCUSL), decided to rename the bill to the Uniform Computer Information Transactions Act and go forward with it.




NCCUSL will vote on UCITA at its annual meeting, July 23-30, 1999 in Denver. There will be a final UCITA drafting committee meeting on July 22, 1999 in Denver. For details on the meeting, contact me at or check

If you read a copy of this article before July 22, 1999, I urge you to write a letter to the members of NCCUSL from your State, asking them to oppose UCITA. If you read it in the July 20-30 timeframe, you can send a letter to me and I will see that it reaches the NCCUSL members from your state. After July 30, send opposition letters to your state representatives.

Why We Should Actively Oppose UCITA

The simple and short answer is that UCITA will dramatically reduce a software publisher's external failure costs for defective software. It does this brilliantly, in a wide range of ways, reducing the costs of customer support, of lost sales due to competition, and of legal action.

As a result, UCITA changes the economics of software publishing.

When we reduce the risks (to the publisher) of selling defective software, we reduce the incentive to spend the money and time to prevent, search for, and fix defects. In turn, this tells me that we (the American software industry):

What We Can Do

For the last three and a half years, I've spent about one-third of my time, unpaid, explaining software quality issues to legislative drafting and regulatory bodies. I've provided input to drafting committees for Uniform Laws (Article 2B/UCITA, Article 2—UCC law of sales, and the Uniform Electronic Transactions Act), to people drafting laws and treaties to govern international electronic commerce (a State Department study group, and members of the American Bar Association), to the Federal Trade Commission, and to various consumer protection groups. Several other software quality advocates have shared in this work, including Watts Humphrey, James Bach, Doug Hoffman, Sharon Marsh Roberts, Melora Svoboda, Ken Pugh, Brian Lawrence, and Bob Johnson. Software-related professional societies, including the Association for Computing Machinery, the Institute for Electrical and Electronics Engineers, the Independent Computer Consultants Association, and the software-test-discuss mailing list (but not ASQ) have submitted letters criticizing UCITA/Article 2B.

Here are a few things that I've learned.

First, UCITA is just one of several legislative proposals involving software quality that will go to the state and federal governments over the next few years. It is currently the most important. I expect to also see proposals to:

There will probably be plenty of other proposals.

Second, we are credible sources of information on these types of issues. We are industry insiders. We aren't embittered whistleblowers—we want the industry to succeed. We also have special insight—we know how products fail, we understand the difficulties of making perfect products and we also know how our defects affect customers.

Our input is valuable because most of the people who will have to evaluate these proposed laws are lawyers, and most of them are unsophisticated about software. Many of the lawyers working on committees writing legislation to govern electronic commerce didn't even have e-mail accounts when they started work. Many of the lawyers who will vote on these proposed laws still don't have e-mail, let alone more sophisticated e-commerce experience.

Even the ones with some experience as software users get a huge proportion of their education about software development and marketing from other lawyers who represent software publishers. This bias is pervasive. Legislative drafting committees dealing with software are visited or advised by many paid lobbyists for software publishers and by very few, usually unpaid, consumer advocates (almost none of whom have software-related backgrounds). Additionally, courses and industry seminars on software law are typically taught by lawyers who represent software publishers / consultants. And speakers at conferences on software law are typically lawyers who represent publishers. There are hundreds of lawyers working for software sellers, but I can count the number of lawyers who publicly advocate for software quality on one hand.

If legal drafting bodies and legislatures are going to deal sensibly with the proposed laws to govern software quality, they need input from people like us.

Third, we can provide input—we are welcome to provide input—as individuals and as professional societies. People are hungry for our input. Non-lawyers can have a significant impact on laws by addressing technological issues and explaining the consequences of technology-related decisions. Software developers and testers haven't been all that well received in the UCITA/Article 2B drafting committee meetings, but they have had big effects elsewhere. For example, Bob Johnson is responsible for many significant improvements to the Uniform Electronic Transactions Act. And, even in the UCITA process, our comments have been effective in slowing the process down and convincing decision-makers to consider UCITA more carefully. ALI would probably have approved 2B/UCITA if it wasn't for our many comments.

In my experience, regulatory agencies, such as the Federal Trade Commission, are even more interested in our input than legislative drafting groups.

With particular reference to UCITA, we can do the following:




How UCITA Drives Down Failure Costs

The total quality cost for a product is the sum of:

The external failure costs in this model are the costs of the seller or manufacturer, not the costs of the customer. This model ignores the customer's costs (Kaner, 1996).

Normally, the best way to reduce external failure costs is to improve the product, especially by preventing defects or by finding them early in development. However, a company can reduce its external failure costs by handling them (e.g. customer complaints or lawsuits) more efficiently.

UCITA provides another approach—reduce external failure costs directly.

I classify external failure costs into three categories:

Note that the publisher doesn't reduce its customer's losses by reducing these costs. In many cases, the publisher will save money by increasing its customer's losses under UCITA.

Customer Support Costs

Here are some of the ways that UCITA lets publishers reduce their technical support costs (without improving the product). Citations are to the July, 1999 draft of UCITA:

Legal Costs

Here are some of the ways that UCITA lets the publisher reduce its risk of legal liability for defective products, without making the product less defective.

Lost Sales (Especially Sales Lost to Competitors)

In Closing

I've focused this paper on UCITA's impact on software quality, but UCITA has many other serious problems involving electronic commerce and intellectual property rights. If you want details, or if you can offer some help, please write me (


Braucher, J. (1999) "Why UCITA, Like UCC Article 2B, is Premature and Unsound", forthcoming in the UCC Bulletin, July 1999. Available at

Kaner, C. (1996), "Quality cost analysis: Benefits and risks", Software QA, Volume 3, #1, p. 23,

Kaner, C.(1998), "Article 2B and reverse engineering", UCC Bulletin, November, p. 1, See also "The problem of reverse engineering", Software QA,

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: July 25, 1999. Copyright © 1999, Cem Kaner. All rights reserved.