Legal Issues Regarding Defective Software

It's a nightmare scenario. You're charged with heading-up a major custom software modification project for your business. When it's delivered, it's not what you expected. Maybe, it's buggy or slow. Possibly, it takes too many keystrokes to handle basic functions. Whatever it is, you're taking the heat at the office. If you didn't get yourself a well-written contract on the front-end, maybe you've earned the heat when you don't get well-written software on the back end. Possibly, there's some poetic symmetry here.

It's essential that you insist on a contract that clearly states things like what you expect the software to do, how you expect it to do it, how fast it should do whatever it is it's supposed to do and when you expect it to be delivered.

While a contract alone can't protect you from poorly written software, if you take the time to spell out a meaningful warranty and service standard, you will at least have a remedy if things go badly. Moreover, with computers and software, things can go sooo bad. (Sometimes, I hate computers. When they're not working right, they can make you really miserable.)

Ugly Stories about Software

In 1991, software used in telephone switching equipment in five states crashed because of a single mistyped character in the program. It all came down to a "6" being typed where a "D" belonged. This resulted in a nine-hour breakdown. This would be like a long novel being completely unreadable because of a single typo.

In June 1996, the European Space Agency launched its Ariane 5, which had taken almost 10 years to develop and cost more than $7 billion. A mere 30 seconds after launch, the vehicle self-destructed. The defect was in the guidance system software. And you thought you had it bad when tech support told you that to fix your system, you would have to reinstall Windows.

According to the Social Security Administration, 700,000 Americans lost more than $850 million in retirement benefits because of a software glitch that miscalculated benefits for people who continued working while collecting Social Security.

During the Falklands War, an Exocet missile sunk the H.M.S. Sheffield. It turns out that the ship's missile defense computer worked flawlessly in picking up the approaching missile. The problem was that a programming error caused the computer to identify this missile heading straight toward the ship as "friendly."

If a sailor had made that error, you might ask him (at the top of your lungs, one-inch from his face with spit flying of course), "How could you possibly think that a missile coming from the known location of an enemy ship flying directly towards us was 'friendly?'" I suppose that this makes the point that among the many things computers lack is common sense.

A 1997 report by Computerworld Magazine made a number of interesting points about software and software development.

From a legal perspective, 12 percent of companies had faced liability or litigation from the lack of software quality and 69 percent didn't have systematic software testing procedures.

Defective software caused 54 percent of the surveyed companies to repair software after delivery, 47 percent had cost overruns, 33 percent had down time and 25 percemt had a weakened competitive edge or missed market opportunity.

Finally, 90 percent of the developers surveyed had missed ship dates within the last year. (You're not really holding your breath on delivery of a Y2K fix in the last quarter, are you?) Sixty-seven percent missed deadlines on a routine basis, and 91 percent have been forced to "remove key functionality late in the development cycle to meet deadlines."

As for the root causes of poor software quality, Computerworld cites inadequate training of managers and staff, inadequate defect and cost measurement, excessive schedule pressure, insufficient defect removal, high complexity levels, and ambiguous and creeping requirements and design.

Preventing Litigation

The one thing that experience as a computer lawyer has taught me is that the majority of disputes are caused by the failure of the parties and their lawyers (if lawyers were even involved) to adequately detail the product the vendor was expected to supply. So then, what can you do to improve your process with the goal being better communication between buyer and seller?

It starts with a carefully drawn and detailed development agreement. The primary purpose of this agreement is not to set the developer up for a lawsuit. Rather, the primary purpose is to foster communication so that buyer and seller are truly on the same page.

If properly represented, each side will try to gain certain advantages in the negotiation process and that's as it should be. Such is the nature of any business negotiation.

If you're a software developer, you'll want to limit the remedy available to the buyer. Typical provisions limit the buyer to repair or replacement of the software, or refund of the purchase price. You'll also want to limit or, better yet, eliminate consequential damages. Be careful here. This type of drafting is not for do-it-yourselfers. These limitations must be precisely drafted.

If you're a buyer, pay careful attention to certain red flags in a contract. Some of these include warranty disclaimers, remedy and liability limitations (no matter what we do to you, you get a refund as your only remedy,) and estimated pricing and project completion dates. If the nature of your project requires that you accept estimated pricing and completion deadlines, then you need to build in some safeguards. For example, you might make sure that progress payments are tied to progress not arbitrary dates and that you have input along the way so that you can control pricing and features.

An often-contentious issue is the question of a Year 2000 Capability Warranty. As we sit here in 1999, there is no excuse for not negotiating for a meaningful Y2K warranty.

"We warrant that the software is Year 2000 capable" is simply not a meaningful warranty. I'm often asked what's the difference in the meaning between terms like "Year 2000 capable," "Year 2000 ready," "Year 2000 compliant," and Year 2000 certified." The answer is that there is no difference in meaning. They're all meaningless.

A complete checklist of all the possible components of a definition of these terms might include more than a dozen subparts. Sorry, but you can 't meaningfully fit that entire message into three words like "Year 2000 capable."

Your lawyer must carefully negotiate a Y2K definition that is meaningful to you in context. If your definition of "Y2K capable" includes, as it should, that the software have a four-digit interface for the year field (01/01/2000 and not 01/01/00), you may learn from your vendor that they were planning on a two-digit field for the year.

The beauty of this bit of communication at the planning and contracting stage is that you get to discuss this point before you pay for the software and before you have anything about which to fight. You may find that two-digits suits you just fine in this particular context. Alternatively, you may need to ask about the price change if you go with four-digit years.

The most important point is that "Year 2000 capable" has no inherent meaning. In this example, to your vendor, it meant a two-digit year field. To you, it meant something else. This is why your lawyer must take the time to carefully define this term. Moreover, this is but a single example of the confusion, disagreements and possible litigation that could ensue if you don't deal with these issues before you sign a contract.

The moral of this story is that high-tech contracting requires time and effort to ensure that you properly write the "deal" into a meaningful contract. The old cliché, "Garbage in, garbage out" certainly applies to the relationship between the effort put into the agreement going in versus the software that comes out at the other end of the development process.