Papers on the Law of Software Quality
- Quality-Related Costs. The Economics of Software Quality
- Checklist for Software Testing Outsourcing
- Software Negligence and Testing Coverage
- Liability for Defective Documentation
- Liability for Defective Content
- Computer Malpractice
- Liability for Bad Software and Support
- What is a Serious Bug? Defining a “Material Breach” of a Software License Agreement
- Lawsuits, Lawyers, and Quality-Related Costs
- Uniform Commercial Code Article 2B: A New Law of Software Quality
- Not Quite Terrible Enough Software: Remarks at the 1997 Software Engineering Process Group Conference
- Legal Issues and Software Quality: Keynote presentation at the7th annual meeting of the Software Division of the American Society for Quality
One of the core goals of quality engineering is to reduce the total amount of a product’s quality-related costs. These costs include money invested to make the product better (for example, preventing or finding bugs), and money wasted coping with the product’s bad quality (for example, money spent on recalls). Quality cost analysis is a standard part of traditional quality control. This paper applies it to software.
On the legal side, this paper warns of a problem. When you do quality cost analysis, you make cost/benefit judgments which might lead you to fix some problems or to leave them in the code. Unfortunately, the analysis doesn’t consider the customer’s costs, just the company’s. As a result, the analysis might lead you to leave some completely unacceptable bugs in the code, resulting in litigation.
Testers aren’t the only people who love checklists! Lawyers like them too. Whenever there is a complex contract to be negotiated, lawyers look for checklists that cover the issues associated with this type of contract.
In his courses, James Bach did a good job of explaining the pro’s and con’s of using a software test lab to a testing audience. This checklist takes his thinking a few steps further, explaining the main contracting issues to the lab’s customer. This list will be useful for lawyers, but is written to be comprehensible to the test manager, who may have to explain the technical issues to the lawyer.
On the legal side, this paper explores the concept of negligence, and its application to software products. On the technical side, this paper attacks the myth that you can completely test a program simply by testing every line of code in the program. This is often called “complete coverage.” But it isn’t. Many bugs can survive this modest level of testing. Lines-of-code based coverage is popular because it’s easy to count how many lines have been covered. (You know the old rule — if you can’t quantify it, it must not exist.) I list 101 measures of “coverage.” Most of them are completely independent of the internal structure of the program. There are plenty of other ways to measure the extent of testing. This list illustrates the diversity.
Documentation tells customers what the product does. If it misleads them, they get cranky. As they should. When a seller makes claims about a product to a seller, those claims are warranties. Companies that don’t check the accuracy of their manuals (or their online docs) are asking for trouble. This article looks at the legal rules, and suggests approaches for doing the testing.
Many software products come with additional content, such as fonts, clipart, clip-movies, or text. What if some of the information in this content is mistaken? What if someone loses money or gets hurt as a result of reading something in software? The basic rule is that there is no liability for publishing material that contains mistakes. But there are exceptions. This article explains the rule and explores the exceptions.
Malpractice is a widely discussed type of lawsuit. Unfortunately, it is also widely misunderstood, with misinformation spread in private discussions, in the press, and in political discussions. Several people have insisted to me that software developers are sued “all the time” for malpractice. This is absolutely untrue. This article looks at the history of computer malpractice suits.
This paper reviews eight lawsuits that involve software customer support, and derives several suggestions for the support professional.
A software defect is a “material breach” of a contract for sale or license of software if it is so serious that the customer can justifiably demand a fix or can cancel the contract, return the software, and demand a refund. What standards should we create for this? When is a bug so serious that it should be called “material?” This memo was written for the UCC 2B Drafting Committee, for its meeting on January 10-12, 1997. A related article, for a software testing audience, will appear in Software QA magazine in January, 1997.
Plaintiffs lawyers are often misunderstood by engineers. This paper points out the linkage in goals between in-house quality advocates and consumer protection lawyers.
This article, written for a software testing audience, gives an overview of Article 2B and discusses some of the benefits and some of the problems with the (February 1996) draft.
Not Quite Terrible Enough Software: Remarks at the 1997 Software Engineering Process Group Conference
This paper accompanied a joint presentation that I did with Ray Nimmer in March 1997. It reviews the issues from the perspective of the quality-conscious software engineer, and looks at the issue of quality-related tradeoffs. Article 2B provides no disincentives for selling products with serious, known errors.
Legal Issues and Software Quality: Keynote presentation at the7th annual meeting of the Software Division of the American Society for Quality
This talk ties together issues of theories of software liability, quality cost analysis and UCC 2B.