The Software Conspiracy: Why Companies Put Out Faulty Software, How They Can Hurt You and What You Can Do About It

Page iii

The Software Conspiracy Why Software Companies Put Out Faulty Products, How They Can Hurt You, And What You Can Do About It Mark Minasi MCGRAW-HILL NEW YORK SAN FRANCISCO WASHINGTON, D.C. AUCKLAND BOGOTÁ CARACAS LISBON LONDON MADRID MEXICO CITY MILAN MONTREAL NEW DELHI SAN JUAN SINGAPORE SYDNEY TOKYO TORONTO

Page iv

McGraw-Hill A Division of The McGraw-Hill Companies Copyright © 2000 by The McGraw-Hill Companies, Inc. All rights reserved. Printed in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the publisher. 1 2 3 4 5 6 7 8 90 DOC/DOC 9 0 9 8 7 6 5 4 3 2 109 ISBN 0-07-134806-9 The sponsoring editor for this book was Mary Glenn, the editing supervisor was John M. Morriss, and the production supervisor was Elizabeth J. Strange. It was set in Minion by North Market Street Graphics, 317 North Market Street, Lancaster, PA 17603 Printed and bound by R. R. Donnelley & Sons Company. McGraw-Hill books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please write to the Director of Special Sales, McGraw-Hill, 11 West 19th Street, New York, NY 10011. Or contact your local bookstore. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that neither the author nor the publisher is engaged in rendering legal, accounting, or other professional service. If legal advice or other expert assistance is required, the services of a competent professional person should be sought. —From a Declaration of Principles jointly adopted by a Committee of the American Bar Association and a Committee of Publishers. This book is printed on recycled, acid-free paper containing a minimum of 50% recycled, de-inked fiber.

Page v

To the youngest Minasis, my nephews Michael and Christopher and my niece Megan. May your generation do a better job with the world (bugs included) than mine did!

Page vii

Contents Why Companies Put Out Faulty Software, How They Can Hurt You, And What You Can Do About It Introduction 1. When Some Bugs Bite, They Kill

xiii 1

2. Why Are There Bugs? How Defects Happen

21

3. It Doesn't Take a Genius, It Just Takes a Process: Building Good Software

41

4. Software and the Law

75

5. Bugs and the Country: Software Economics

135

6. Fighting Back: How to Improve Software

163

7. The Future

217

Appendix: Software Self-defense

225

Endnotes

253

Index

263

Page ix

Acknowledgments For such a small book, this required the help of a lot of people, and I want very much to thank them. While the two main ideas that drive this book—that commercial software is a much shoddier product than almost anything else you can buy off the shelf in America, and that it's stunning that as consumer-oriented a society as ours would tolerate it for so long—have been rattling around the back of my head for more than 25 years, I wouldn't have gotten around to putting the notions down on paper without the encouragement of Carolyn Long. Carolyn provided the first spark of inspiration and subsequent encouragement for the book. Kris Shapar, my assistant in 1997 and 1998, combed the Net for background information and beat down doors trying to find people who'd talk to me on the record about shrink-wrap software quality, as well as reviewing my chapters for readability. Cem Kaner, a very capable lawyer and psychologist (now, there's a combination, eh?) specializing in software testing, patiently explained (and re-explained) some of the finer points of contract law visa-vis software to me, enabling me to understand and explain the implications of the frightening new Uniform Computer Information Transactions Act, a law coming to a state legislature near you (and that you'll read about in Chapter 4).

Page x

Brenda Davidson took up where Kris left off and has done a great job editing the final version. Noah Schachtman, an editor at the now-sadly-defunct publishing house Van Nostrand Reinhold, gave me some excellent advice on how to approach the book early on. If Noah hadn't contracted with me to write the book in mid-1996, I probably would never have written it. (By the time it was done, VNR was gone and the firm who bought VNR's remains wasn't interested.) Gary Masters, a good friend, mentor, and associate publisher at Sybex Computer Press, yet another publishing house, offered mountains of advice and helpful criticism; his comments were of continual value. I owe more than I can say to Wendy Rinaldi and Susan Barry of McGraw-Hill. After VNR disappeared in late 1997, I shelved this book project for another time, as I was busy with a different book for Sybex. The following summer, however, I ran into Wendy, whom I've known for several years, in New Orleans. We had lunch and Wendy asked me about my book projects. I told her about this book and she asked to read it, even though it's not the kind of book that her division would publish, and, as she's on the west coast and the rest of McGraw-Hill is on the east coast, she had no particular pull with the noncomputer book folks. I e-mailed the text to her and after reading it she took it upon herself to personally shepherd the book to the editorial director of McGraw-Hill's Professional Book Group, Susan Barry. Since then, Susan and her staff have been a source of constant encouragement and support. My wife Darcee and my friends Christa Anderson, Dina Ralston, Peter Hubbard, and Dawn Farrow read every word of the book and offered uniformly helpful advice. I thank them so much for their time and their effort, as all of their suggestions made the book more readable and accessible to a nontechnical audience—which is this book's intended target. Many people spoke with me on and off the record about the quality—or lack of quality—in commercial software. I greatly appreciate the time that they spent with me, as most of them stood to gain

Page xi

nothing (and many could reasonably expect some reprisal) by speaking with a journalist about this potentially incendiary topic. I owe a lot of thanks to Watts Humphrey, Todd Paglia, Marc Sokol, Debby Meredith, Mitchell Kertzman, Jamie Love, Brad Chase, John DeVaan, John Horch, Wayne Rash, Frank Ackerman, Alyssa Dver, Ed Yourdon, Tom Campbell, Stewart Crumpler, John Murray, Bruce Brown, Ed Foster, Peter Duggan, and many others. It's far easier to work out an argument if you can practice it aloud to an audience, and many professional associations have generously lent their memberships to me for that purpose by inviting me to speak about software quality at their meetings and conferences. Gregg Laird, David Holcombe, George Spalding, Elliot Masie, Wanda Carricato, Eugene Ball, Diana Miller, Gary Lupkin, Craig Matthews, and some others kindly invited me to present my thoughts on software quality to their groups, sometimes to more than a thousand people. These crowds were important sounding boards for my ideas and greatly assisted me in determining the book's direction. Dr. Peter Neumann's Risks forum provided a rich source of information on bugs. Furthermore, it was an on-line source, which is very convenient. In general, I was quite pleasantly surprised at how useful the Web was as a tool for research. Finally, all of these words wouldn't fit together nearly as well without the editorial staff and contractors at McGraw-Hill. Thanks again to Susan Barry, as well as Yedida Soloff, Griffin Hansbury, and Stephanie Landis.

Page xiii

Introduction A software conspiracy? Software company lawyers pack legal drafting committee meetings for over a decade to ensure that software firms don't have to compete by the same rules as every other firm. Companies make software and sell it to the public despite the fact that there are hundreds or thousands of defects in the software, defects that the company is fully aware of when it sells it—but won't tell you about. On the one hand, software companies call their software "mission critical"; on the other hand they deride the idea that they should strive to remove the defects from that software. The conspiracy isn't evil, it's just single-minded: profit is the sole goal, quality (or anything else) is irrelevant. The side effects, however, are not irrelevant. Software defects have killed millions of staff hours. They've killed some great writing, some great figuring, some great ideas. People killed 65 million hours in 1996 waiting on hold when calling software firms for assistance. A lost e-mail message could kill a deal. There's even evidence that it could kill the current economic boom. And, yes, it's even killed people. A seven-year-old boy was killed by bad software in a Chevy truck in Alabama. More than 200 people on a flight to Guam were killed by bad software in an altitude warning device. Twenty-eight Marines were killed when a missile just lost track

Page xiv

of the time, thanks again to bad software. Cyber-murder, you might call it. And where there's murder, you'll find journalists. That's why I wrote this book—I'm a computer journalist. I've been in the computer field for more than twenty years, having written my first program in 1973. Since 1987, I've been a columnist for BYTE, Windows NT Magazine, Nikkei NT, Compute, AI Expert, OS/2, and OS/2 Professional magazines, as well as a contributor to Computerworld, Teleconnect, Programmer's Journal, and Computer Language magazines. I've written sixteen technical books on computers, with over a million and a half sold worldwide in twelve languages. I'm also a frequent speaker at computer conferences in North America and Europe, and do regular radio and TV appearances when hosts need someone who's "technical" but who can speak English. In short, I watch the computer industry for a living. And what I see worries me. I see word processors, e-mail packages, spreadsheets, and Web browser software shipped by large, well-established software companies while those pieces of software are still riddled with defects. Products that literally cannot be made to work reliably. Software entrepreneurs making millions of dollars in profits but claiming that they don't have the time and money to include quality in their design specifications. An industry where 15 percent of the software firms don't even test their software before selling it to you. I wondered why software companies get away with this, particularly in a society as consumer oriented as the United States. So I talked to a lot of people in the business. And I got the same answer, over and over again: "We software firms ship buggy software because you consumers keep buying it. We could build reliable stuff, but no one cares." But I disagree; I think the reason we don't demand quality is that most of us think that software's just supposed to be this way, that it can't be better. But it can. That's why I wrote this book. I have lost countless thoughts and ideas forever to software crashes, and I'll bet you have too. I think

Page xv

we're all tired of having our PCs lock up, forcing us to reboot and lose all of our work. We're tired of calling a software vendor's technical support line for assistance, only to be told in patronizing tones that there's nothing wrong with the software, you just need to learn to use it properly, dummy. And I wrote this because I think that demanding good software is easy once you know a few things—things I've put in this book. The computer industry has traditionally used jargon and technical detail to separate itself from its consumers; in this book, I've done my best to keep things understandable to all and even, I hope, entertaining. I've also tried to make this as industry-wide an indictment as is possible. Many people I corresponded with seemed to think that this book would or should focus on Microsoft, but that's not my intention: bugs are a problem for every software vendor, and Microsoft by no means has the corner on bugs. Yes, we hear a lot about bugs in Microsoft software, but that's largely because Microsoft is so big—of course we'd be more aware of bugs in Microsoft software, as they affect so many people. Chapter 1 is a short overview of the rest of the book, the ''executive summary'' for those who don't have the time to absorb the whole book all at once. Chapter 2 looks at bugs in detail, asking why software has defects and what the common defects are, and provides some sensible advice on how to cope with common bugs in the software you use. Chapter 3 explodes the myth that software firms want you to believe—the myth that "it's impossible to write software without bugs." Chapter 4 takes you into the world of software and the law, an area that's become frightening recently with some proposed changes to U.S. laws—changes that would forever establish that it's perfectly okay for software firms to sell you completely useless software and leave you no recourse whatsoever. Worse yet, those same software firms can show up at your door unannounced with a federal marshal and close down your business while ransacking your computers looking for software you didn't pay for. Chapter 5 explains that bad software could have very large effects not just on each of us individu-

Page xvi

ally, but on the country as a whole. America essentially owns the software market, but if we're not careful, we'll lose it as we've lost so many others to our competitors across the seas. And Chapter 6 offers very specific, simple, step-by-step things you can do to help solve the problem of buggy software—everyday things anyone can do. Finally, Chapter 7 puts the rest of the book in perspective by offering a view of the possible futures—both good and bad—that could arrive if something does or doesn't happen to change the quality of commercial software. This book is only the starting point on a long journey to reliable software. To keep up on the latest in this area, or to offer comments or war stories of your own, e-mail me at [email protected] or visit www.softwareconspiracy.com. In the software business, programs that sell extremely well are called "killer apps." Ready to meet a few killers? Then turn the page and join me for Chapter 1.

Page 1

Chapter 1 When Some Bugs Bite, They Kill "The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version that I ever heard.... And so, in no sense, is stability a reason to move to a new version. It's never a reason. You won't get a single person to say they'd buy a new version because of bugs." —Bill Gates, CEO of Microsoft, quoted by reporter Klaus Brunnstein of FOCUS magazine, 4 November 1995

Page 3

You have to wonder if he'd feel that way if a Year 2000 bug eliminated all of his financial records on January 1, 2000. Are bugs really not a problem? Is software of sufficiently good quality? Vernon Kidd, The Montreal Life Insurance Company, and twenty-eight U.S. Marines deployed in Dhahran during the Gulf War probably wouldn't think so. A Rogue's Gallery Vernon Kidd must have been initially alarmed to hear in 1986 that he had cancer, as anyone would be. But his doctor probably assured him that it was just skin cancer, and that it would be relatively simple to cure him—he no doubt had a terrific chance of recovery. Before Vernon could enjoy that recovery, however, he was dead—literally killed by a buggy piece of software that converted a radiation therapist's order to use a low-power, tumor-killing radiation beam into a high-powered, human-killing X ray. The therapist had originally accidentally set the radiation machine, a device called the Therac-25, for a fatal dose of X rays, then realized her mistake and changed the dosage. The computer software, however, was erroneously designed to ignore her correction, instead treating Mr. Kidd with 25,000 rads. He died less than a month later.1 In 1982, the Montreal Life Insurance Company, one of the largest insurance companies in Canada, decided to upgrade its billing software. Like many financial firms, Montreal Life had turned to computers early on as a way to make its massive record-keeping tasks less labor intensive and more accurate. Banks, insurance companies, and brokerage houses were all computerized long before many other industries. Montreal Life's new software was troublesome, however:

Page 4

agents were either paid more or less than they were owed, leading to lawsuits and losses, and by 1985 the owners were forced to sell off the remainder of the company. Put simply, bugs in the new billing software had killed the business.2 In the Gulf War, the U.S. lost a total of 146 soldiers. By the early evening of February 25, 1991, fewer than fifty had died; come the morning, however, that number would increase by half. The army's Patriot missile had racked up an enviable record in tracking down and destroying incoming Scud missiles during the Gulf War, seeming to create an invincible shield around U.S. forces. The shield failed that night, however, allowing a Scud to successfully strike a building serving as an armed forces barracks. Twenty-eight died, the largest single set of fatalities for U.S. forces in the Gulf War. The Patriot failed because its guidance software was fairly accurate, but stopped working properly after fourteen hours of continuous use; in essence, a Patriot missile battery needed to be "rebooted" every fourteen hours or it became unreliable. That Patriot battery hadn't been rebooted in over 100 hours.3 The Kidd, Montreal Life, and Patriot stories are particularly sensational cases of software failure, so they made the papers. But everyone who's ever used a computer has had software disasters; while thankfully no one usually dies, someone's time and/or money is wasted. The story "Software Crashes, People Lose Data" is hardly "Man Bites Dog." In fact, a headline like ''Software Package X is Useful and Never Crashes"—now, that would be a journalistic event! Bugs Are Defects Bug is just a cute word for defect; when you buy buggy software, you're buying a defective product. Is that bad? Well, software is a manufactured product, just like hamburgers or cars. If burgers regularly killed people or gave them food poisoning, the firms that made them would soon be out of business. In fact, as this book was being written, that very thing happened to a beef packer, Arkansas-based Hudson Foods. In mid-

Page 5

1997, Hudson shipped frozen beef patties unintentionally infected with E. coli to supermarkets around the country. The contaminated patties made fifteen people sick (no one died), and the uproar that ensued resulted in Hudson's departure from the marketplace by late August 1997, after twenty-five years of operation. But software companies regularly give us "data poisoning"—why do we let them get away with poor quality, while holding other industries to a higher standard? Software failures are frustratingly common. Everyone who's ever used a computer has run across a software failure. Have you ever had your computer simply "freeze up" on you, not responding to any commands and forcing you to turn the computer off, losing your work? Have you ever lost entire files because your word processor hiccupped? Installed a child's game on the family computer and had it destroy your existing configuration? Been told by the IRS that your tax return was incorrectly filed, only to find out that the incorrect entries were the result of a bug in your tax preparation software?4 (This is a sadly regular occurrence among the popular tax programs.) Then you've been bitten by a computer bug. But did you then call the software vendor looking for a fix, some recourse, or at least an apology? What you probably got was a skeptical attitude from the vendor's support person; essentially you were told that it was really your fault. Perhaps most unbelievable is this scenario. You experience some kind of problem and call the software vendor, looking for a fix. The vendor's support person asks you to reproduce the problem while on the phone. You can't, so the support person says essentially, "Have a nice day," and blows you off. So you work and work to make the problem an easily reproducible one (which can take quite a bit of time and effort), basically proving the existence of the bug. You call the vendor back and start to explain the nature of the bug in detail, but once the support person hears that you're well informed about the bug, he cuts you off. "That's a known bug," you're told. "We hope to fix it in the next release.'' This don't-admit-bugs-until-you-must strategy is commonplace in the software

Page 6

business. According to Cem Kaner, software quality and testing expert, 90 percent of the bugs consumers report to software vendors are already known to the vendors. Perhaps more amazingly, the vendors had full knowledge of those defects when they decided to ship the product. Believe it or not, fully 15 percent—one in seven—software firms surveyed about software quality said that they regularly shipped out software that they'd never even tested.5 Try to imagine even the possibility of this in other industries. Suppose you're cruising down the road in your new car and you signal a turn while at the same time turning down the radio a bit. You're stunned when the steering wheel locks, and you can no longer change the car's direction, causing you to crash. You're further stunned when, after a bit of prodding, the car's manufacturer admits that yes, they knew that this could happen, but it seemed unlikely—who adjusts the radio volume while turning?—so they decided to save money and time and not fix the problem before shipping the car. Now, if an automobile manufacturer did this, then before you could say "class action," some consumer group would pull out its records of other victims of the same car model and file papers against the automaker. But in the software world, it's just business as usual. Why Do We Put Up With It? The odd part about all this is that in America, we normally don't tolerate unsafe or shoddy products. That's not to suggest that it's unusual for a company to react to a product problem by blaming the consumer rather than the company's own engineers; denial is a common reaction in both people and companies. It is, however, odd that we'd tolerate that reaction in a country where a court told McDonald's to pay a woman $14 million in damages because she didn't know that spilling hot coffee on herself would hurt! In a society of consumer-oriented lions, we lay down like little lambs when presented with software excuses. Why? How did this happen?

Page 7

There are probably three reasons why we tolerate low-quality software: computer experts tell us that defect-ridden programs are normal, the industry press largely ignores bugs, and software vendors aren't convinced that bug-free software sells. Mentors And Teachers Say Bugs Are Okay It's partially the fault of computer experts. Once, someone introduced you to computers. She showed you how to turn on the computer, load the software—word processor, Internet browser, game, or whatever—and start doing some work or having fun. But eventually something unexpected happened; you did something that the software didn't like, and it crashed. You were puzzled, and looked over at your mentor, who furrowed her brow. "Why would it do that?" she might have mused. "Well, that's just Windows for you. I guess I should have mentioned that it's a really good idea to save your work frequently." The unspoken message from your trusted computer authority was: Hey, it's a tough old cyber-world out there, kid, stuff happens. Quit whining and just retype that text. This wouldn't have happened if you'd saved more often, you know. I understand this because in the past I've been as guilty as anyone of fostering low expectations about computer reliability. When I first started working with computers twenty-five years ago, virtually everyone using a computer was an expert to some degree; there weren't really any end users. Back then, I (and everyone else around at the time) learned to accept unreliable software because computers were at that time in what I call the dancing bear phase. Did you ever go to the circus and watch dancing bears? You don't say, "Hey, that music is in 3/4 time and the bears are dancing in 4/4 time"; no, you just say, "Hey, wow, bears dance!" I had a similar reaction to early PCs. Early word processors were wobbly, but, hey, no more white-out! The backspace key tells no tales, if you know what I mean—quite a feature for a young writer whose typing is fast but not terribly accurate, so

Page 8

computers impressed me. Having to put up with a few rhythm-challenged waltzing grizzlies seemed a reasonable exchange for the benefits of computing. I transferred that attitude to many of my protégés, as did they to theirs; but we've got to stop doing that now. It's no longer reasonable to assume that everyone who uses a computer is willing to become a computer expert. The market has changed, often without the experts noticing, and they—we—don't always realize that the average computer user not only isn't a computer expert, he probably doesn't want to become a computer expert. Everyone has an e-mail account nowadays; that's a big difference from ten years ago, and it means that software must work better, must be more reliable and forgiving. Computer Magazines Say Bugs Are Okay The computer press doesn't help matters. If a computer magazine publishes a roundup of word processors, the central piece of that article will be the "feature matrix," a table showing what word processing programs have which features. With just a glance, the reader can quickly see which word processors have the richest sets of features, and which have the least features. You can see an imaginary example in the following table: Can boldface text

MyWord 2.1

BugWord 2.0

√

√ √

Runs on the Atari 520 Automatically indents first line of a paragraph

SmartWords 3.0

√

Includes game for practicing touch typing

√

√

Lets you design your own characters

√

√

√

√

Generates document tables of contents

√

Can do rotating 3-D bullet points in color Can do bulleted lists

√

Supports Cyrillic symbol set

√

Includes Malaysian translator

√

√

Page 9

Just offhand, it looks like BugWord 2.0 is the clear value—there are lots more check boxes in its column. However, a closer look reveals that it lacks some very basic and useful word processing features, which MyWord 2.1 has. But the easy-to-interpret visual nature of a feature matrix seems to mean that the magazine's message is: Features are good, and the more the better. As Internet Week senior executive editor Wayne Rash, a veteran of the computer press, says, "Look at something like PC Magazine, you'll see this huge comparison chart. Every conceivable feature any product could ever do shows up, and if a package has that particular feature, then there's a little black dot next to that product. What companies want is to have all the little black dots filled in because it makes their software look better."6 In contrast to features, the trade press doesn't discuss bugs very much at all, although not for the reason that most people think. As a writer for over a dozen computer journals over the years, I've never been told to tone down an article because it would offend advertisers. I have been told by editors that readers don't want to read "negative" things, and I've been shown by editors' actions that while I'm free to write all the bubbly, gushing prose I want about a product, I needn't worry about producing sources or proving the validity of that congratulatory text. If, however, I write something negative about the product, then I'll need triple proof in writing, complete with smoking guns. After I spoke to a crowd of several hundred in August 1997 on the subject of software quality, several members of the computer press came to me to agree—strictly off the record, of course—with this. One writer for a prominent technology magazine that prides itself on being hip and irreverent related to me how he was told to remove an anti-Microsoft comment from an article because the magazine feared repercussion from Microsoft CEO Bill Gates and a forced retraction of any negative statements that couldn't essentially be proved in court. 7 In short, magazines aren't afraid of offending advertisers, they're afraid of looking stupid. Feature matrices are fairly neutral, safe ways of filling pages.

Page 10

Many magazines stress timeliness over quality in their coverage of the computer industry. ''Companies don't get incentives for taking their time and turning out good stuff," says John Horch, a software quality consultant with over forty years of experience programming for computers large and small. "Apple recently announced that their multiplatform development tool Rhapsody would ship late. What did we see in the press? Was Apple congratulated for doing the right thing? No, the headlines were 'Apple is late again.' What message does that send to programmers? 'Don't be late' not 'Get it right.'"8 Software Vendors Think Consumers Say Bugs Are Okay We buy shoddy software because our mentors told us it was all right and because the computer press doesn't bring quality to our attention—but what about the software vendors' role here? They provide the third leg of the software quality tripod, a wobbly stool indeed. One of the reasons we tolerate bad software is that none of the software vendors really provide the option to buy high-quality software. "You know what's needed before we get good software?" posits John Murray, software quality guru for the U.S. government's Food and Drug Administration. (John is the guy who is trying to make sure that a bug in Grandpa's pacemaker doesn't stop his heart on New Year's Eve 2000.) "Cars in this country got better when Japan showed us that cars could be built better. Someone will have to show the industry that software can be built better." Wayne Rash agrees, saying, "The Japanese and Europeans came in with better cars and it forced us to get better. That may well happen. Some company somewhere will come up with a product that's distinctively better because of its quality. There are people who claim that SAP [the German producer of R3, a manufacturing management program] has done that—I'm not qualified to judge whether or not it's true, but I sure have noticed that all of a sudden SAP owns the world in databases, and I don't

Page 11

think that's by mistake, and I don't think it's because people want to speak German. So if what I'm told is true, we're seeing a quality revolution in at least one market already." 9 Every software executive I interviewed for this book agreed on two things: first, that writing software with very few bugs would be simple, and, second, that they believed that no one would buy it, as buyers focus almost entirely on features and very little on quality. The quote at the beginning of this chapter clearly indicates that Microsoft's founder believes this—but he's not the only one. Listen to Microsoft's chief technologist, Dr. Nathan Myrhvold: I did a study of a variety of Microsoft products: I counted the number of lines of code for successive releases ... Microsoft Word was at 27,000 lines of code in the first version. ["Lines of code" is a rough approximation of a program's size.] It's now about 2 million.... If I say I've got two versions of Word—[an] old one from 1982 that's perfect, with zero defects, or [a] new one that's got all this cool new stuff, but there might be a few bugs in it—people always want the new one. 10

It's worth noting that while Dr. Myrhvold's a very smart guy, he's dead wrong here about one thing: no former version of Word ever had zero defects. Further, the latest version of Word doesn't have "few" bugs. Microsoft admits to 214 known bugs in Word 97, and no one knows how many actually exist.11 Interestingly, Myrhvold then added, "But I wouldn't want them to operate a plane I was on with software that happened to be the latest greatest release!" Others at Microsoft agree, including Brad Chase, Vice President of Internet and Tools Marketing for Microsoft's Internet Platform. Brad said to me, "I'll tell you something: no user ever said to me, 'Give us less features.' " So I asked Brad, "So you folks set the features-versus-bugs dial based on what you see the market as demanding?" His answer was a clear, "Definitely—and the market demands features."12

Page 12

But Microsoft people aren't the only ones who don't believe that there's consumer interest in quality. Marc Sokol, senior VP for advanced technology at Computer Associates, said to me, "The market [for consumer and desktop software] is not quality sensitive. You try to take on some market leader with higher quality. Can you charge more for it? I don't think so." Debby Meredith of Netscape, Vice President of the Client Products Division, oversees the development of Netscape's Web browser, and she echoed these sentiments, saying, "Our expectation isn't that any one given release is perfect and has zero bugs—but if that was our goal, we could accomplish that ... that's not the balance that our customers are asking for."13 No one should suggest that software isn't difficult to write, and Myrhvold's earlier comment indicates that it's not getting any simpler. Building a word processor is at least as difficult as engineering a bridge, probably more so in some ways. Furthermore, there isn't really a large body of knowledge about building error-free software, certainly nothing like the huge disciplines that an engineer can draw upon when designing a bridge. (And, as one person I interviewed observed with a grin, when an engineer messes up and designs a lousy bridge and the bridge falls down, there's lots of evidence.) But there's ultimately really one reason why software companies keep selling buggy software: Because we let them. "As long as the public is willing to buy crap, they're going to get crap, says Watts Humphrey, a Fellow at CarnegieMellon's Software Engineering Institute.14 (Mr. Humphrey is the creator of a software development process that has allowed companies like Boeing and Motorola to build software with zero bugs—you'll meet him in Chapter 3.) Bug-Free Software Isn't Impossible But is it really that easy? Is it reasonable and fair to demand low-defect software? Years of putting up with computer bugs has led the average

Page 13

software buyer to think that high bug counts are as inevitable as death and taxes. But people in the industry know better. When asked whether or not software could be higher in quality, virtually everyone interviewed for this book answered somewhere in the range from "Sure, of course" to "Certainly, but software would be more expensive. Programmers are craft workers, people who enjoy building things. And I've never met a programmer who would get up in the morning saying, "Boy, I'm really gonna go turn out some lousy code today!" Rather, every programmer I've ever met wants to be proud of his or her work. Programming is a job that allows the joy of creation, and no one wants to create low-quality stuff. But because the software industry has convinced itself that consumers respond to features and not quality, bottom-line-conscious managers in that industry define a product as finished when it's only half-baked, move the programmers to other tasks, and then ship the half-baked products. Nevertheless, there are many well-documented examples of high-quality, reasonably priced software, albeit in places you don't think of as containing software. For example, have you ever owned a cellular phone? A cell phone is a pretty complex computer in some ways, with a fairly large program running in it (roughly the same size as Windows 3.0 was, in the case of some cell phones). But in years of using a Motorola cell phone, I've never had my phone "crash." I've never seen a set of keys that, if pressed, caused nonsense characters to appear on the display, or caused the phone to stop responding to keypad inputs. "That's true," comments Ed Yourdon, programming guru, adding, "and not only that, but if your cell phone did lock up, we'd never accept it. We have a completely different set of expectations for cell phones."15 It is entirely possible to write cleaner programs. NASA's Pathfinder mission to Mars relied upon a fairly large computer program that had to work the first time—running the beta version of Pathfinder over to Mars for a bit of testing just wasn't possible. And NASA

Page 14

did a great job, and at a good price—under $4 million for the program. Surely NASA hasn't cornered the market on top-quality programmers; there's been no "brain drain" from Microsoft, Lotus, Borland, Corel, and other "shrinkwrap" software (the term for mass-market commercial software, most of which is sold in shrink-wrapped boxes) firms to NASA! But not everyone believes that the average piece of software is buggy entirely because of perceived consumer demand. One former CEO of a large software company, who asked not to be named, had this to say to me: "Look at Microsoft Office 97. It's buggy and the trade press said, 'don't buy it,' but people are still buying it. They just shove it down people's throats and get away with it—but that's not really Microsoft's fault, in a sense: after all, if Ford could ship without any concern for quality, shipping cars six months early that are lemons and people would buy them anyway, then Ford would probably do that, right?"16 You'll hear more from that former CEO in Chapter 6. Bad Software Hurts The Economy Some feel that firms like Ford (and other U.S. automakers) did ship without any concern for quality decades ago, when the U.S. essentially owned the worldwide automobile market. In 1967, we sold many more automobiles to other countries than they sold to us, creating a huge trade surplus. By 1996, however, software—despite being a small part of the overall U.S. economy, less than 1 percent—generated a larger trade surplus than any other industry, about $20 billion. And $20 billion is, by the way, about the size of the trade deficit created by the automobile market in 1996. Deficit? What happened to that surplus that automobiles generated in 1967? Well, we got sloppy and shipped unreliable, gas-guzzling cars to a world market with very few alternatives. Could it happen in software? Nowadays, one of the reasons we can afford to buy cars and VCRs from other countries is because those countries buy software like

Page 15

Windows, Quicken, and Oracle from us. But if we think that they'll stand still while American companies force bug-ridden—that is, unsafe—software down their throats, we're wrong. Consider that one way that modern software is different from older software is that it takes more and more memory—or, in computer-speak, more RAM. Think of these pieces of software as ''RAM guzzlers," and you can see where the future of the software industry might lead. Eighteen of the twenty largest software firms in the world are American. The vast majority of the shrink-wrapped software sold in the world is made in the U.S.A. If keeping this vital market from slipping away is important (and it is), then quality must become a visible, talked-about aspect of shrink-wrap software. The software marketers and the software-buying public must stop focusing on the thousands of mainly unused features and start focusing on reliability. Volvo sells a lot of cars because people perceive its cars as safe; Toyota sells a lot of cars because people perceive its cars to be reliable. Imagine a world where an ad for a American-built spreadsheet program might take on a foreign competitor, saying, "An independent testing laboratory determined that our WizCalc spreadsheet program has 41 percent fewer bugs than the competition's MagicCalc—so buy WizCalc." "Uniform"-ly Bad Software In the past, industries producing low-quality goods either faded from view, were spurred on to greater quality by competition, or, in extreme cases, were required by law to produce better quality. The very notion of attempting to regulate software quality would be anathema to most nowadays—but how would most people feel about creating laws that actually encourage low quality, officially condoning bad software? Believe it or not, it's happening, in a process that is unfolding even as you read this. The computer business has created a whole slew of problems for the legal system. Computers and the information that they create,

Page 16

transfer, and modify don't fit exactly into our standard laws governing the buying and selling of goods. As laws must change with time, however, there are two organizations of lawyers that work together to propose new laws to reflect that need for change. The American Law Institute (ALI) and the National Conference of Commissioners on Uniform State Laws (NCCUSL) have collaborated since 1923 to create some of the major pieces of business legislation, and to promote uniform adoption of this legislation across the fifty states. Eleven years ago, ALI and NCCUSL tried to create a set of laws that would institute a framework for buying and selling software, databases, and any other kind of information. Unfortunately, the process got hijacked by the software industry, leading ultimately to an historic rift between ALI and NCCUSL—the proposed legislation apparently just wasn't good law in the eyes of ALI, so NCCUSL decided to take its football and go home, proposing the law as the Uniform Computer Information Transaction Act or UCITA and bypassing ALI altogether. The act, if passed, would essentially set in stone the notions that software need not be of any quality at all, that software vendors can sell you junk and there's nothing you can do about it. Should it pass, UCITA would be a tonic to the software business initially, but in the long run it could well destroy the American software industry. How would this counterintuitive result occur? Well, consider what would happen if we made the U.S. a safe haven for buggy, unreliable software. Quality would drop, causing non-U.S. firms to buy more and more software built outside the United States. The non-U.S. software firms would slowly grow and produce better and better software, as the American firms just kept on doing business as usual, with no incentive to improve. Eventually, the foreign software firms would have the money and the quality to take on the U.S. market, and that would be the end of American hegemony in the software market, and perhaps even the end of domestic content software. But UCITA isn't law in the fifty states yet, and every American can be

Page 17

part of the process—you can read more about it in Chapter 4. For a speculative look at the long-term effects of UCITA, read Chapter 7. Fighting Back But enough complaining—what can be done? That's a long answer, and we'll take it up in detail in Chapter 6, the largest chapter in the book. But here are a few thoughts. First is this basic fact: remember that software firms can only keep shipping low-quality software as long as we keep buying it. We can make better buying decisions if we have good information about product quality, but computer magazines in general aren't oriented toward discussing the bad along with the good; write magazine editors and tell them that you want to see negative reviews as well as positive reviews. Treat bad software like any other low-quality product: if it doesn't work, return it and get your money back. Many software stores will not accept returns on software, but most software licenses currently offer your money back within 90 days of purchase. And in the process, tell the vendor what it did wrong. Write a polite but firm letter explaining that you rely on applications and will not accept unreliable ones. Tell software vendors you won't accept garbage. With polite but firmly worded letters, tell vendors you want quality. Don't automatically buy upgrades: when a program goes from version 3.1 to 4.0, don't assume the newer version is better. If you're thinking of buying an upgrade of some important software for your business, think twice: new software not only introduces new bugs, it creates costs in terms of needs for new training and, usually, new hardware, as newer software tends to be slower software. If you owned a 1998 Ford Taurus, would you automatically "upgrade" when the 1999 or 2000 Taurus came out? For most of us, the answer is a puzzled, "No, of course not." Start thinking that way about software upgrades. And don't buy an upgrade simply because you hope it'll fix defects in a

Page 18

product you've already paid for. If that 1998 Taurus had an unreliable electrical system, would you just shrug your shoulders and say, "Well, I guess I'll just buy the 1999 model, maybe that works better," or would you insist that Ford fix the product it sold you? (The latter, I hope.) If you don't get satisfaction from the software vendor, tell the world. There are places on the Web to post bug information; write up bugs you've found in shrink-wrap software in a polite, firm manner, and share this information with others. Write computer magazines with the information. File complaints with the Better Business Bureau—computer companies now attract more complaints than used car dealers! Demand quality, but help the vendors create it. Ask them (again, politely but firmly) to stop focusing on features for a version or two and instead zero in on shaking out the bugs. Tell them you'd even be quite happy with software with fewer features if it never crashed. Most vendors distribute early versions of their software, called beta versions, for free to interested customers. This software is still under test, and so will be more unstable than the average software. People using beta software are assisting the vendor in developing a better final product. (They're sometimes rewarded with a free copy of the final shrink-wrap software.) During the beta process, vendors listen, and they listen well. Join beta programs, and be vocal. Don't let the U.S. become a safe haven for bad software. Contact the commissioners of the organizations creating the revised Uniform Commercial Code and complain about the proposed revisions. And while they're modifying the rules for doing business, why not require vendors to reveal some vital quality information? Every software vendor ships products with hundreds and sometimes thousands of known bugs, bugs that are shrink-wrapped into the package. Why not ask (or require) software vendors to list all of the known bugs in their software on their Web sites? Similarly, why not require them to post return rates of software?

Page 19

Don't accept software excuses from others. When your bank tells you it can't give you your balance because the system is down, ask why. (More on this strategy in Chapter 6.) Nowadays, all a company has to do is blame some problem on software and we all just say, "Oh, yes, of course, I understand." But we shouldn't; a company that runs its information systems department poorly is just a poorly run company, plain and simple. Worse yet, "The computer is down" has become an excuse that companies use when it's not even true, which ought to make you worry about how often we'll hear it in the year 2000 due to the so-called millennium bugs. Software is important to us individually as people trying to get work done, organize busy lives, protect important data, or perhaps just to have fun, and to the nation as an engine of economic growth. Through most of its history, the software industry has been mesmerized by newer, "cooler" features, with quality taking a back seat. But features are toys; reliability is a responsibility. It is time for the software industry to lay aside the toys of childhood and take on the responsibilities of adulthood. New software's most important "feature" should be reliability. When I speak or write about the need for greater quality in software, a developer will sometimes angrily respond, "Okay, smart guy, why don't YOU tell us how to write code with fewer bugs?" It's an interesting response, for an historical reason. Around the turn of the century, a similar discussion was going on in the meat packing industry. The industrialization of the beef industry had led to the growth of huge slaughterhouses, and the sanitary conditions in those plants were terrible—packers would open the slaughterhouses in the morning and literally have to sweep a layer of bugs and rat dung off the meat before getting down to work. European buyers complained about the quality of the meat, and some early consumer advocates started agitating for more sanitary conditions in the industry. They were told that such measures would raise the price of beef so high that the consumer would not accept it. The very idea that Hudson Foods

Page 20

would be driven out of business just because a little over a dozen people got sick would have been unbelievable in 1897. Today, however, the event was no surprise at all. What changed all that? Mostly a change in consumer expectations. In 1905, Upton Sinclair wrote about the conditions in the meat packing industry in The Jungle, and the next year the federal government passed the Meat Inspection Act of 1906. Somehow, the beef industry survived being ''debugged"; I imagine the software industry could as well. Big software companies may say that reliable software would cost them too much, but, again, some of them see profits of over 20 cents on the dollar17—surely a few cents spent on safety, and reliability isn't too much to ask? And recall the question made by the CEO who asked not to be identified: couldn't a lot of companies make money if they didn't have to worry about quality? In some senses, though, we consumers shouldn't even care about how better code gets written. Sure, it's hard to write good code. But it's hard to design good, reliable cars, and we do that now. And yes, it's hard to keep the rats out of the slaughterhouses, but we do that now. The fact is that in most of American society, you're just not allowed to sell shoddy stuff. In this country, if you sell junk, we put you out of business, plain and simple. Once, we cut the software companies some slack because they were young. They're not young any more. So if you're mad about bugs, don't let someone bog you down with lots of statistics about bug rates and lines of code. Instead, borrow from Nike's corporate slogan and tell 'em, "Just Do It." The first step to demanding better software is to learn to speak a little of the language, and to understand just a bit about where bugs come from and what some of the more common varieties are. We'll do that next.

Page 21

Chapter 2 Why Are There Bugs? How defects happen

Page 23

On August 10, 1987, Mr. Ford Lewis first drove his brand-new 1988 Chevrolet 2500 pickup truck. Two days later, he'd put 200 miles on his new vehicle. On the 12th, his daughter Helen Lewis Johnston came to visit him, bringing along her seven-year-old son Bart. Bart and his grandfather went off on an errand and eventually came to a major intersection outside one of the larger towns in Marengo County, Alabama, where they all lived. Seeing things were clear, the grandfather pulled out. In the intersection, however, the truck stalled. Looking down the highway, Lewis saw an 18-wheel tractor-trailer loaded down with logs about 700 feet away and coming fast. He frantically tried to restart his truck, but it wouldn't start. The driver of the eighteen-wheeler blew his horn and belatedly realized that the pickup couldn't move. The trucker veered to the left—but not soon enough—and struck Lewis's truck. When the dust cleared, Lewis was hurt and his grandson dead. Inside Lewis's truck was a small computer of a type you've probably heard of—a fuel injector. The fuel injector computer's program had some bugs in it. GM knew about the bugs and released a fixed version of the program, but rather than do a full-scale recall, they figured they'd only give the new program to customers who complained.1 Unfortunately, seven-year-old Bart Johnston never got a chance to complain. In the resulting lawsuit, General Motors v. Johnston, 592 So.2d 1054, 1992 (Supreme Court of Alabama), the Alabama Supreme Court told GM to pay Johnston $7.5 million. Much of this was punitive damages as a known defect in the truck killed Bart. The very idea that an automaker would let a potentially life-

Page 24

threatening defect remain unfixed seems inconceivable in the post-Pinto years, and yet GM left the defect unfixed, begging the question, "Why?" GM most likely didn't feel compelled to fix the fuel injector bug because it was a special kind of defect: a software defect, rather than a structural defect. And unfortunately we seem to think differently about software defects than other kinds of defects. That kind of thinking has got to change, but it can't change until people understand bugs better—hence this chapter. In this chapter, we'll get three things accomplished. First, you'll learn how we came to call software defects bugs in the first place. Second, you'll learn how bugs creep into computer programs by writing a short program of your own—and in case you're worrying that it'll be too technical, don't: anyone can write this program! Finally, few things help understanding more than examples, so we'll look at four particularly well-known or egregious types of bugs. Edison, Grace Hopper, Bogeymen, And Bugs How did we come to use a synonym for insect to mean software defect? Although most people think the term bug is a fairly new one, it's not. According to Dr. Peggy Kidwell of the Smithsonian Institution, it's been around since at least the nineteenth century. "Using bug to mean a glitch in electrical systems was current in Thomas Edison's day," Dr. Kidwell explains. "He used the term in this sense in legal testimony—a court case wherein he was cross-examined in 1877—in a magazine article he wrote, and in some correspondence in 1878."2 Apparently, Dr. Kidwell relates, the term was already in common usage among engineers. She knows these things because she assembled a recent exhibit for the Smithsonian on ''Computer Bugs, Past and Present,'' and because she is in some ways the custodian of a very important bug. But why bug? According to the Oxford English Dictionary, the

Page 25

common word bug, used when referring to an insect, may actually have developed independently of the word bug that now refers to a glitch or problem. The latter meaning of bug as it relates as an object of dread or fear apparently first arose in the sixteenth century. It shares roots with bogey, bogeyman, and the less used but once more frequently heard bugbear. This common blurring of the two meanings of bug has lead to a well-known but inaccurate story, supposedly based on a real insect, about where the term came from. In 1947, the Navy operated something called the Bureau of Ordinance Computation, based at Harvard University in Cambridge, Massachusetts. The bureau used some of the first computers in order to plot trajectories for large guns. These computers were based on electronic relays, small switches that can be automatically opened and closed with electromagnets. Every time a zero became a one or vice versa, a relay would click, leading one engineer to remark that the computers sounded like "hundreds of people knitting madly." The second of the bureau's computers, a huge machine named the Mark II, ran in a building without air conditioning—remember, this was 1947—and on the particularly warm morning of September 9, 1947, the Mark II's programmers decided to open the windows in a vain effort to cool off. One of those programmers was Lt. Grace Murray Hopper. Just as the programming day began, the Mark II stopped working altogether. In an effort to figure out what had gone wrong with the Mark II, Hopper and her coworkers ran a series of diagnostic tests on the computer. Finally, at 3:45 P.M., during a test called the multi-adder test, they were able to narrow the computer failure down to just one relay, relay #70 Panel F. A look inside showed the problem—a moth had flown into the jaws of the relay, rendering the switch unable to fully close. Hopper pulled the moth from the relay with a pair of tweezers and taped it to the operator's logbook, noting wryly, "First actual case of bug being found." 3 Many people think that Hopper coined the term at that point, but it's clear from the log entry that the phrase was already

Page 26

current at the time. Both Grace Hopper—eventually Admiral Hopper, one of the first female flag officers in the U.S. Navy—and the bug went on to become famous, Admiral Hopper for inventing COBOL (among other things in an illustrious career) and the bug because the Admiral was a popular speaker, and loved to tell the story of "the first bug." That logbook is now in the hands of the Smithsonian Museum of American History, in Dr. Kidwell's care. In the final analysis, however, programmers probably prefer bug because, as one of computing's earliest theoreticians, Edsger Dijkstra, once wryly observed, it sounds better: "It's so much easier to admit 'my program still has some bugs in it' than to say 'my program is still full of errors that I made.' "4 Write Your Own Program Let's demonstrate how bugs creep into software by writing a little software of our own and seeing how programmers get their jobs done. Try this exercise. Take out a sheet of paper—make it a big one—and a pen, and write down the exact steps for starting up a car and backing it out of a driveway. Try it now, before reading the next paragraph. (Come on, really do it. Don't just keep reading: take a minute and try writing the instructions.) Finished? You just wrote a "program." Let's see how you did. Does your program include instructions to turn the key in the ignition? To look behind the vehicle and adjust the path of the car as it travels down the driveway? To adjust the path of the vehicle using the brakes, accelerator pedal, and steering wheel? Most folks would remember that. Did you remember that the driver should release the parking brake? Fasten her seatbelt? Fewer people usually think of that. If you have a vehicle with automatic transmission (and don't live in San Francisco or Seattle), then you may never use your parking brake, and so you might have forgotten it.

Page 27

How about an instruction that says, "If it is dark outside, turn on the headlights?" "If the car is in a garage, open the garage door before pulling out?" Or, somewhat more esoteric but not a bad idea, "Check that the car's inspection sticker is valid and that there is sufficient gas to reach the intended destination?" A computer program is essentially the very same thing—a set of instructions that describe how to get a particular task done. But the instructions must describe how to accomplish that task exactly, and that's where the problem arises. If you were one of the small number of people who remembered to tell the driver to fasten her seatbelt, did you also include an instruction for the very small number of cars that lack seatbelts? No? So did you, as the programmer, make a conscious decision to ignore the needs of the drivers of very old cars without seatbelts, or did you just forget? Or, upon rereading the instructions, did you perhaps realize that you accidentally put the instructions in the wrong order? And you were probably assuming that the person executing the program spoke English: how would a non-English speaker fare with your program? An IBM programmer I heard speaking at a conference once likened writing a program to writing a book. "It's like writing War and Peace," he said, "—but with no typos." While that's a great image, and one that compels us to feel sympathy for the programmer—who could write a book that size without errors?—it's not quite accurate. On average, commercial programs have about 14 to 17 errors per 1000 lines.5 One thousand lines corresponds to about 20 pages of book text, but well-edited books have considerably less than 17 errors in 20 pages. Algorithms: Explanations For Computers Actually, what you just did wasn't exactly programming—it was the first step in programming. In this first, most important part of writing a program, you need to come up with an English-like description of

Page 28

how to get the desired task done, just like your explanation of backing up the car. This description must be a clear, unambiguous, step-by-step explanation of how to get the job done. Here's an example. Suppose I want to write a very simple program to determine what percent of your income you paid in taxes last year—your overall average tax rate. Here's my English-like step-by-step description of how to get that job done: 1. Tell me how much money you made (in dollars) last year in total. I'll call that INCOME. 2. Tell me how much money you paid in taxes, also in dollars. I'll call that TAXES. 3. I then divide TAXES by INCOME, multiplying the result by 100. I'll call the resulting number TAXRATE. 4. I will then tell you that you paid TAXRATE percent in taxes last year, substituting the word TAXRATE for the actual value that I calculated in step 3. Simple, direct, and clear. This step-by-step explanation is enough to get started writing a program. By the way, computer professionals don't usually take the time to say "step-by-step explanations," as they have a handy word that means the same thing: algorithms. Strangely, the word is actually a corruption of a nickname of a man famous for publishing a number of these step-by-step procedures.6 One of the first people to formally describe how to accomplish many complex mathematical functions was a ninth-century Arab mathematician named Abu Ja'far Mohammed Ben Musa al-Khowarazmi. It's said that his book, essentially the first treatise on algebra, was so essential a reference that it prompted Europeans at the time to stop using Roman numerals and instead to adopt Arabic numerals, which we still use today. al-Khowarazmi was known in his time as "the man from Khiva," his hometown. When somewhat corrupted by English speakers, the Arabic version of the

Page 29

phrase "the man from Khiva" comes out sounding like the syllables "al-go-rhythm." al-Khowarazmi wrote about so many step-by-step procedures that any step-by-step procedure became known by his nickname, algorithm, just as today we might slyly characterize a married man who'd been unfaithful as having "pulled a Clinton." Tools For Programming: Programming Languages After developing an algorithm, programmers take the next step: converting the algorithm to a programming language. That's because no matter how well described an algorithm is, no computer can use it—at least not yet. You see, computers don't take direction in English; they take it in any number of specialized languages designed specifically for computers, called "programming languages." Most programs on large mainframe computers are either written in a language called the COmmon Business Oriented Language (COBOL)—Admiral Hopper's language—if they're business applications, or a language called FORmula TRANslator (FORTRAN) for scientific applications. Most programs written for desktop computers, the PC and the Mac, are written in a language called C. C doesn't stand for anything; the language got its name because it was the successor of another language called B. B, in turn, succeeded—no, not A, but BPL, the Basic Programming Language. BPL, B, and C were all invented at the old AT&T Bell Laboratories. Simpler programs on PCs are often written in an easier-to-learn language named the Beginner's All-purpose Symbolic Instruction Code, or BASIC. BASIC programs are easier to write, but are more wasteful of the computer's power than are C programs, and so BASIC programs run more slowly than equivalent C programs. More than likely, the word processor, e-mail package, or Web browser you use was written in C. Here's my earlier "calculate your tax rate" example, implemented as a simple BASIC program:

Page 30 INPUT "How much did you make last year in dollars"; INCOME INPUT "How much tax did you pay"; TAXES TAXRATE = TAXES / INCOME * 100 PRINT "Your average tax rate last year was "; TAXRATE ;" percent." END

Run this program on a computer, and it'll look something like the following. What the user types is printed here in italic, what the computer types is in normal type. How much did you make last year in dollars? 34000 How much tax did you pay? 11000 Your average tax rate last year was 32.35294 percent.

Let's see how this extremely simple computer program works. The first line is an INPUT statement. The INPUT statement puts a question on the computer screen and waits for the user to respond. The program will store whatever number the user enters in an area in memory, an area that it sets aside and calls INCOME. The next statement does the same basic thing, asking a question and waiting for an answer, then saving the answer in an area in memory set aside by this program named TAXES. The program then divides the value in TAXES by the value in INCOME (the slash is computerese for divide) and multiplies that by 100 to get a percentage (the asterisk is computerese for multiply), which it stores in a third location named TAXRATE. (In case you're wondering, computers don't come out of the box with pre-assigned areas called INCOME, TAXES, and TAXRATE. Instead, the computer has memory or Random Access Memory [RAM] that it can use for any number of purposes. When running a program like this BASIC program, the computer just temporarily sets aside a bit of that memory and temporarily labels it INCOME, TAXES, TAXRATE, or whatever.)

Page 31

Programmers might refer to these five lines of BASIC as a program, or they might call it code—programmers use the words program and code, and, to a certain extent, application, interchangeably. What you or I might call a word processor or word processing program, others might call a word processing application. Those five lines of code are a childishly small program compared to real-world applications; it's not unusual for commercial applications to consist of millions of lines of code—and that number is growing. Recently, Microsoft president Steve Ballmer has been reported as saying that Microsoft's much-anticipated Windows 2000 is up to 40 million lines of code. Let's see ... assume 15 bugs per thousand lines of code and that comes out to 600,000 expected bugs. Thus, if Windows 2000 is built to "standard" industry quality, it will have more bugs than this entire book has words. I sure hope Microsoft aspires to better than that! Even my simple BASIC program has a flaw—did you catch it? Tell your eight-year-old to run the program, and the result run might look like the following. How much did you make last year in dollars? 0 How much taxes did you pay? 0 Error 281: divide by zero System halted.

Since the eight-year-old had no income and paid no taxes, BASIC tried to compute TAXRATE = 0/0, and, as no one knows what the value of zero divided by zero is, the program just "blew up." A better program would have first checked to see that INCOME wasn't equal to zero before trying the division. Four Notorious Bugs While anything can cause a bug, the fifty-plus years that people have been building programs have yielded some patterns and recurring

Page 32

sources for bugs. While chances are good that you don't program and never will, understanding some common bugs can help anyone—programmers and users alike—recognize a bug. In the next few pages, you'll meet four of the most common software pests: the famed Year 2000 bug, its cousins the lesser-known date bugs, the fixed precision bug, and the syntax error bug. Year 2000: An Ill-Timed Bug Most bugs are unintentional, but some bugs are actually intentional—that is to say, they were designed into the system. Perhaps the most famous design bug bit Produce Palace International, a Michigan-based seller of fruits and vegetables. Back in 1996, Produce Palace International started experiencing problems with its cash registers—now and then, every cash register in the store would crash, all at the same time. The cash registers are, like many devices these days, just special-purpose computers that only run one program. This cash register program, sold by a firm named Tec America, had an Achilles' heel: if you asked it to validate a credit card with an expiration date after December 31, 1999, it crashed, taking all attached cash registers with it. After 105 crashes, Produce Palace International sued Tec America, settling for $260,000 in damages.7 The Year 2000 bug comes from a programming practice originally intended to save memory. Computer programs store dates as sequences of numbers, so, for example October 7, 1999 might be stored as 10071999. But a programmer can save space by only storing the last two digits of the year, as in 100799. Fewer digits means faster programs and less space taken up in computer storage, so the six-digit format, also known as MMDDYY, often won. This is not, by the way, a trivial thing: if one digit takes up one byte of storage space, then storing a million dates with MMDDYY would require six megabytes of disk storage and MMDDYYYY would require eight megabytes. In

Page 33

today's world, two megabytes doesn't sound like a lot, but thirty years ago disk storage cost well over a million dollars per megabyte.8 So MMDDYY seemed like a great idea in the '50s, '60s, and '70s, when the turn of the millennium seemed far away. No one expected a program to have a useful life beyond ten years or so; unfortunately, that changed, and businesses and government agencies got more cost conscious and attempted more and more to reuse previously written code. As a result, many "modern" programs consist of layers upon layers of progressively older code, much of which still stores dates as six-digit groups. Computer programs must often calculate days of the week so as to answer questions like, "What day of the week did 14 October 1997 fall on?" A very common day-of-week calculation algorithm uses as a crucial piece of information the fact that 1/1/1900—1/1/00 in many programs—was a Monday. For two-digit year systems still working after 1999, the fact that 1/1/2000—again, 1/1/00—is a Saturday will cause problems. Such a problem has already appeared on a Sony VCR that uses this algorithm. After the year 2000, suppose you program the VCR to tape your favorite TV show every Wednesday at 8 P.M. The result will be that the VCR tapes the show every Friday at 8 P.M. For those with non-Y2K-compliant VCRs, however, there's a workaround: tell the VCR the year is 1972, as the relationship of day of the week to day of the month cycles every 28 years. Some systems still use two-digit year arithmetic, but have craftily pushed the Year 2000 bug off a few years with something called a sliding window algorithm. Microsoft and Lotus programs will support both two-digit and fourdigit representations of years, but the two-digit representations are more prevalent. If you type 1/1/10 into an Excel spreadsheet, however, Excel will (probably correctly) interpret this as 1 January 2010. 1/1/90, however, is interpreted as 1 January 1990. How does it do it? Give Excel 95 a year value between 00 and 19, and it puts the value after 1999. Given 20 to 99, it'll place that date in the twentieth

Page 34

century. Excel 95 is, then, year 2000 compliant, but will have a year 2019 problem! (For those Excel 95 users who are concerned, there is a workaround—build your spreadsheets using four-digit year numbers.) When using twodigit dates, Access 97 has a problem after 2028; Lotus's Smart Suite products, which include the 1-2-3 spreadsheet and the Approach database, run into trouble with two-digit years after 2049—again, however, users can ward off this problem with four-digit years. So the ''Year 2000 bug'' will be around long after 2000. Other Date Bugs The year 2000 is not the only date that gives computers fits. The most common date bugs show up on leap years and on year changes in general. If a program runs constantly, day after day, and it must keep up-to-date calendar information, then the programmer must put some intelligence into the program about our quirky calendar system. Where's the logic to having some months with 30 days, others with 31 days, and one oddball month that morphs from 28 to 29 days and back? There isn't much logic to it, but programs must understand it nonetheless, and that means a relatively large amount of programming. In the process of date coding, programmers may forget that on the day after December 31 they must not only change the value of the month from December to January, they must also change the year, incrementing it by one. This sounds like a small item, but it's not—a space shuttle launch was postponed from 31 December 1989 to 1 January 1990 over fears that some undiscovered change-of-year bug would crop up.9 Many PCs have a bug in them that prevents the PC from knowing what day it is, even if it knows what time it is. Under some circumstances, older versions of the common PC operating system MS-DOS update time and date information by asking another piece of system software, "What time is it, and has the day changed since I last asked?"

Page 35

Suppose someone leaves work on Friday, leaving her PC on for the weekend. The PC isn't asked to do anything during the weekend, so DOS never has a reason to ask, "What time is it, and has the day changed since last I asked?" When the employee returns on Monday morning and starts working, DOS will update the time and note that the day changed. But because the last day that DOS knew about was Friday, it assumes that the day is now Saturday. Result: the machine loses two days per week.10 Fortunately, most people reboot their computers at least once a day, and so this bug never arose for the vast majority of PC users. (This doesn't happen on computers running Windows 3.1, Windows 95/98, or Windows NT.) Leap years cause programmers fits as well. Liquor licenses in Iowa expired on February 28, 1992, but the new licenses didn't take effect until March 1, 1992, due to a programmer's neglecting to include February 29. A San Diego parking lot cash register computed the period of time between February 29, 1992 and March 6, 1992 as 342 days. You might say that was balanced out by an Avis car rental program that didn't charge for February 29. A leap-year bug in NCR automatic teller machines caused the ATMs to refuse customers' cards and to corrupt those cards. 11 Limited Precision Bugs Some bug stories are real and some are folklore, but probably the most authoritative collection of these tales is on an Internet forum called "Risks," moderated by Dr. Peter G. Neumann. You can find Risks at http://catless.ncl.ac.uk/Risks on the Web, or via FTP at ftp://ftp .sri.com/risks. Dr. Neumann is a principal scientist at SRI International in Menlo Park, California. Back in 1985, he created Risks as a clearinghouse for information about computer-related failures. Running Risks is only a part-time job for him, but his Risks database is a gold mine of stories about what can happen when too much virtual reality and real reality collide. In 1995 Neumann published a

Page 36

book called Computer Related Risks (Addison-Wesley, New York, 1995), which contains some of the highlights of Risks and is required reading for anyone not yet convinced that bugs do matter. A look through Computer Related Risks and the Risks online forum shows that a fair number of bugs arise from a condition called limited precision. I have an example of limited precision right on my desk, in the form of a calculator. The calculator can only exactly display numbers with ten or fewer digits; it can represent larger numbers using something called scientific notation, but once it starts doing that, the numbers are no longer exact. Why does my calculator only display ten digits? Because adding more digits would require more circuits in the calculator, which would drive up the calculator's cost, and the manufacturer (probably correctly) made the decision that the vast majority of its customers would need no more (and would be willing to pay for no more) than ten digits of precision. While the limiting of the digits—the precision—of my calculator doesn't cause me any great hardship, something like limited precision has destroyed at least one spacecraft. Soon after takeoff, the European Space Agency's Ariane 5 began to veer off its course, following instructions from its inertial guidance computer. At the computer's direction, the rocket assumed an angle of attack that caused the multistage booster to literally begin to fall apart. Internal sensors detected that the stages were about to come apart—the booster was designed to fly vertically, with the second stage firmly in place below the first stage, rather than horizontally—and activated a self-destruct mechanism. What caused the inertial guidance system to give such goofy instructions to Ariane 5? One of the inertial guidance system's attitude sensors—the thing that tells the booster whether it's flying vertically or horizontally—failed. The inertial guidance system then began paying attention to another attitude sensor. The problem with this other attitude sensor, however, is that it was normally only intended to function when the spacecraft is on the launching pad, where it's normally vertical, give or take a few degrees. The input's value was

Page 37

larger than the limited precision of the sensor could represent, causing it to "overflow" when the rocket veered off, leading to the problem.12 Fixed precision forces computers (and calculators) to discard some information simply because they don't have enough bits to store all of the information. One such precision error appeared in Microsoft's Windows 3.1 Calculator program. If a user tried subtracting 3.0 from 3.1, the Calculator program would report that the answer was zero! This led to jokes in the industry along the lines of, "Want to see the difference between Windows 3.1 and Windows 3.0? Just use the calculator to show that the result is: nothing!" By the time you read this, a much-awaited fixed precision problem will have occurred. The satellite-based Global Positioning System (GPS) is not primarily designed to act as a time source, but GPS signals contain date and time, and many terrestrial systems needing an accurate, precise source of time and date information pull that information from GPS. Part of the GPS date information is the week number—the number of weeks since 5 January 1980. (That date is just an arbitrary starting point—don't look for any deep meaning in it.) The problem arises because the largest week number the GPS program knows how to count to is 1023, and the 1024th week after that 5 January 1980 starts on 22 August 1999. On midnight of August 21/22, then, the GPS week information could potentially appear to be reporting a date of 1980.13 Now, this is most definitely not a bug; GPS was designed to roll over roughly every nineteen years. True, it's a bit inconvenient for programmers building GPS-aware applications, but only being able to count for nineteen years at a time made the system more workable; storing dates that way is compact, and so information transmits more quickly. GPS's designers fully explained this in the original GPS design documents. Where the problem comes in is that there are a number of GPS-using machines whose software wasn't designed to be smart enough to anticipate the date rollover, and so some GPS-dependent devices will have gone dead or have malfunctioned in late August 1999.

Page 38

Dotting The I's: Syntax Errors Perhaps the most frustrating kind of error is called a syntax error, usually nothing more than a keying error. Some of the most amazing stories of this type come from the aerospace industry, which has been using computers to control real-world things like aircraft and space vehicles for over forty years. Some of these stories are documented; others have come down through the years as folklore. One of the first syntax stories falls in the folklore category. The Soviet Union's October 1957 launch of Sputnik I created a panic among American politicians, scientists, and engineers to get an earth-orbiting satellite up in space. One of the government agencies attempting this was the U.S. Navy, which tried to orbit a satellite named Vanguard. While Vanguard satellites did eventually get off the ground, the first two exploded on liftoff, computer folklore has it that the culprit was a computer program that contained a semicolon where a comma was needed. In another case, a navigational program for the U.S.'s first manned orbiter, Project Mercury, computed inaccurate orbital information during the earliest, suborbital flights. 14 Before attempting a full orbital mission, NASA looked more closely and discovered that a line of a FORTRAN program that should have read DO I=1,10 instead read DO I=1.10—a period where a comma was needed. The DO statement is a command in FORTRAN that tells a computer to do something over and over again, a so-called loop. DO 1=1,10 means, "Do the next thing I'm going to tell you ten times." In contrast, DO 1=1.10 just says, "Do this once," because there's no comma—a DO statement with only one number runs only once. Because NASA reuses its programs, this navigational program in some form assisted in course computation for other spacecraft as well. Had the bug not been found, the trips to the moon might well have ended in failure and a lost crew or two. In a similar (and better documented) case, Mariner I, a Venus probe, had to be destroyed by ground controllers six seconds after

Page 39

takeoff. A postmortem analysis reported: "NASA-JPL-USAF Mariner R-1 Post-Flight Review Board determined that the omission of a hyphen in coded computer instructions transmitted incorrect guidance signals to Mariner spacecraft boosted by two-stage Atlas-Agena from Cape Canaveral on July 21. Omission of hyphen in data editing caused computer to swing automatically into a series of unnecessary course correction signals which threw spacecraft off course so that it had to be destroyed."15 For want of a hyphen ... On To Quality Now you understand a bit about how software development works, and how it can not work. In this chapter, you've gotten a glimpse of how a program gets designed, seen a small sample of program code, and learned how bugs can easily creep into that code. From there, you've also learned about some of the most common types of bugs, including the now much discussed Year 2000 bug. And you've got a framework for analyzing and discussing bugs as well as some strategies you can use to cope with buggy software until the day comes that quality software finally becomes commonplace. Can quality software become commonplace? Many people think so—and you'll meet them in the next chapter.

Page 41

Chapter 3 It Doesn't Take A Genius, It Just Takes A Process: Building Good Software

Page 43

Early on the morning of 6 August 1997, eleven-year-old Rika Matsuda dozed on her mother's arm, lulled by the hum and rumble of the Boeing 747-300 carrying the two of them and 252 other passengers and crew to Guam's Agana International Airport. At 1:37 A.M., 254 passengers and crew awaited the routine touchdown of Korean Airlines flight 801, a flight from Seoul, Korea. In five minutes, Rika's mother and 223 others would be dead, killed in part by bugs. At 1:42 A.M. Guam time, Flight 801 crashed into a hillside overlooking the airport. 1 Basically, the pilot flew too low and ran into the ground. He must have realized his error in the last few seconds, as Rika remembers him getting on the loudspeaker and saying without preamble, "Everything will be okay." Rika's small size allowed her to crawl through a hole in the wreckage before a fire started by the crash could reach her seat. She's okay, but will never see her mother again.2 That almost certainly wouldn't be true if a piece of software called the Radar Minimum Safe Altitude Warning (MSAV) system had been better written. MSAV senses the location and altitude of aircraft in its vicinity and tells airport controllers when a plane flies too low so the controllers can then tell the pilot. So were the controllers just goofing off that night? No. MSAV had a troublesome bug that caused it to frequently issue false alarms; the airport at Agana was running "upgraded" software that fixed these false alarms—apparently a bit too well. Before the "fix," the system covered an area sixtythree miles around; after the fix, it only sensed aircraft altitude problems for one mile around. The MSAV sensor was about eleven miles from the airport, and so did not sense Flight 801's imminent doom. In other words, the MSAV programmers were tired of hearing

Page 44

people complain that the MSAV system announced too many near-crashes. So, instead of making it more judicious in its analysis, they just desensitized it. Bad software killed the passengers and crew of Flight 801. And at this writing, no one's been indicted in connection with their pointless deaths, and you can bet no one ever will be. If only MSAV's programmers had sought to write nearly bug-free code. "Ummm... you don't think that's really possible, do you?" a marketing representative for one large shrink-wrap software company diplomatically said to me at a recent meeting of Digital Equipment Corporation support people. (She didn't work for Digital, she was just attending the conference.) This is a common attitude, as everyone "knows" that bugs are an inevitable fact of life. But, of course, at various times in the past everyone's known that tomatoes were poisonous, or that the Sun moved around the Earth. And, of course, everyone was wrong then. In fact, it absolutely is possible to build low- or zero-defect software. In this chapter, you'll meet some of the people who know how. You'll see that by using some simple disciplines—software design processes—some experts have demonstrated how to build good software, often without increasing the software's cost. The main impediment to general acceptance of these disciplines is an old and familiar one: programmers, like the rest of us, don't like change. They like doing things the way they've always done them. An Exercise In Building Cleaner Code Before getting into the chapter, however, permit me to put you to work again, as I did in the last chapter, with another experiment in programming. As before, I'd like you to write down a step-by-step process—but this time, instead of backing a car out of a driveway, write down the steps to preparing scrambled eggs. This time, however first find a friend and run the friend through the back-out-of-the-

Page 45

driveway exercise. Let him or her make the same kind of mistakes that you made. Then try this. Both of you should each sit down and write out the goal of this project—just a sentence or two about what the scrambled eggs program is supposed to do. Take a minute and note what you learned from the first program you wrote—some thoughts about how you'd do better the second time. Then each of you should write the program. Then, one at a time, present your program to the other person for his or her comments. Put the book down and try this, right now. What was the result? Did you remember to check that there was a frying pan in the house before starting the procedure? Similarly, did you cover the need to create a nonstick surface on the frying pan? To collect the salt and pepper and have it nearby before starting to cook the egg? How about specifying that the eggs must be chicken eggs, as scrambling ostrich eggs would be a similar procedure but would take longer? You probably didn't get all of the details, but you're likely to have gotten many of them correct. That's partly because you were more practiced at "programming," and partly because you used a very tiny version of an important programming practice called a design process, something we'll talk about in this chapter. But as you read on, remember the fact that a process improved your resulting programs. Not surprisingly, having some kind of process greatly improves programs, and programmers who use a process of some kind not only turn out cleaner code, they also save money along the way. Oddly, however, 30 percent of the companies writing software have no software process at all, as you'll learn in this chapter.3 "Can't Be Perfect" Is Different From "No Quality Control Necessary" It's probably currently impossible to build perfect programs, to guarantee that a given piece of software has no defects at all. Unfortunately, that has led most people to think: "Well, since there's no way

Page 46

to prove it has no defects, it's unfair to hold software vendors to any standard of quality.'' That sounds reasonable on the face of it, but other types of firms must also design big, intricate systems while managing defect rates, and they do so with much more success. As Watts Humphrey of Carnegie-Mellon's Software Engineering Institute says in a short paper entitled ''Comments on Software Quality," "Modern commercial aircraft, for example, are very complex hardware and software systems. One cannot definitively prove that all design and manufacturing defects have been removed from a large aircraft. This, however, does not prevent aircraft manufacturers from warranting their products or from taking full responsibility for product quality."4 Watts ought to know about quality in software, since he's been working on it for decades. I first saw the results of his work a quarter of a century ago, although I didn't know his name at the time. My first college programming classes back in 1974 required programming assignments completed on the university's IBM 360 mainframe. What I remember most about that old, slow system was its comparative reliability. The 360 would crash now and then, certainly—but not all that often, perhaps once a month. It certainly didn't crash and require rebooting every few hours like so many modern PCs, and its operating system ran in less space than Windows 3.1 did on a PC. But IBM mainframe software wasn't always like that; earlier mainframe operating system releases were fairly wobbly. One of the people behind the 360's operating system (called OS/360) was Watts Humphrey. In part of his twentyseven-year IBM career, Humphrey was the director of IBM software development. In a lengthy interview, he explained to me how IBM lowered OS/360's bug count. "Quality methods in software are nothing new," he says. "In 1966, when I was made director of software [at IBM], I went around to the programming shops; it was the first thing I did. I was appalled. I went to our leading labs and wanted to see their schedules and plans. Nobody had any.

Page 47

"And I really didn't know what we should do, how we should develop software to do it the best way possible. So I asked the programmers how to do it. And the answer was obvious to them. 'Well, we'd make schedules,' they'd say. 'We'd make plans, and that's how we'd do it.' So I asked, 'well, why don't you do that?' Their answer was 'we don't have time.' " The programmers weren't the cause of the problem, though, contends Humphrey. "Well, the point was, it wasn't their fault; it was my fault. My fault as the executive manager. I'd just been in the position a month, so it wasn't entirely my fault, but to a large extent it was. It appeared that I was willing to tolerate crappy work, and as long as I'm willing to tolerate crappy work, that's what I'm going to get." "Producing first-class stuff needs a process approach to do quality work. I mean, you don't get first-class symphonies with just garden-variety conductors. If you just wave a stick around, you'll only get good music."5 A Plan For Quality: The Capability Maturity Model So what did Humphrey do? "Well, in those days, we were shipping this new hardware but the software wasn't getting out, and it wasn't good when it did get out. The previous software director had been fired. I just went into my group executive's office and told him that I was going to stop everything. He turned pale. But I told him, we're never going to get out of the hole until we start insisting on doing this stuff right, and here's how you do it right. I've got to do this. It'll take me about 60 to 90 days to get a plan and get this stuff straightened out. We've got to stop everything and get a plan or we'll never get out of the hole." After this didn't get him fired, Humphrey went to all of the individual project managers.

Page 48

"I told them, you will have on my desk a signed document with your detailed plans for what you're doing, approved by all the people who are participating in your project, or you will not be allowed to announce ship dates for products; in fact, I won't fund your development projects until I get those plans. I'm giving you the time to plan and get it right." The result? IBM started shipping mainframe operating system software on time and functioning properly. Years later, after retiring from IBM, Watts Humphrey decided that he "didn't want to just play golf and sit on the beach," so he worked to apply what he'd learned to programming in general; that's where the Software Engineering Institute (SEI) enters the story. The U.S. Department of Defense (DOD) started the Software Engineering Institute in 1984 at Carnegie-Mellon University in Pittsburgh. Its objective, according to Humphrey, was to "fix the software crisis." He continues, "DOD's view was that people knew how to do software a lot better than they were doing it, which was absolutely correct." Humphrey brought his design approach to SEI. "I worked with the Air Force, and the key question they were concerned with was, 'How do you select software contractors?' As is normal, they were selecting contractors based on bids. And we think—and thought—that's a bad approach. A manufacturer wouldn't buy computer chips from someone based on a bid—he'd go look at the plant where the chips are made, see how the chip maker's company works. So we put together a framework and said, 'This is what we think first-class programming organizations look like.' '' That evolved into something called the Capability Maturity Model (CMM). CMM describes five levels of quality for software development organizations. CMM is actually fairly simple, in Humphrey's words: "An organization at level 1 is basically not doing much of anything. At level 2, they're doing some planning, tracking, configuration management, they make some noises about quality assurance, that kind of stuff. A level 3 organization begins to define

Page 49

processes—how they work, how they get things done, trainable things. At level 4 they're using measurements. They have a framework for actually tracking and managing what they do, something statistically trackable. Level 5 organizations have a continuously improving process. It basically just follows the Deming model of quality, it's standard quality stuff, but adapted very directly to software. CMM was first published in 1987." [W. Edwards Deming was the American management specialist who helped rebuild postwar Japan and founded the notion of Total Quality Management.] In ten years of CMM, have the DOD and other users of this system seen results? Yes, and SEI can track this through the training it provides for programmers. SEI compared the number of bugs per thousand lines of code for the students in four different training sessions. Comparing the number of bugs in the first two programs each student group wrote to the number of bugs in the last two programs they wrote, SEI found from 64 to 83 percent fewer bugs. Additionally, the programmers turned out more code per hour; one group's hourly productivity only rose by 22 percent, another's by 136 percent. Not bad—better code in less time! Another SEI study showed that people who adopted CMM saw a fivefold return on their investment.6 "The quality improvement per year—that's reduced defects, customer defects, was reduced 39 percent per year. The development cycle time was reduced by about 19 percent. There's a Motorola laboratory in Bangalore, India, that I visited a couple of times that has achieved level 5 proficiency. In the three years since they were formed and incorporated the CMM process, their productivity has improved 16 times. The last two megabytes of code they shipped had 24 defects, total" Humphrey explains (so that's why those cell phones are so reliable). Humphrey's not the only person advocating something like this, by the way. Drs. Victor Basili and Richard Shelby of the University of Maryland have been working for years to perfect a model called the Experience Factory (among other locations, you can find a several-page write-up at Basili's home page, http://www.cs.umd.edu/~basili/).

Page 50

It's a process based on decades of experience and many experiments trying to find out what works. In its simplest terms, the Experience Factory just suggests that programmers should try things and keep track of what works, much like CMM. How many lines of code does each programmer produce each day? How many bugs did each find today? Dr. Basili says that the Experience Factory "recognizes the fact that improving the software process and product requires the continual accumulation of evaluated experiences ... in a form that can be effectively understood and modified... stored in a repository of integrated experience models that can be conveniently reused." 7 All Dr. Basili's saying is that we should get better at learning from our mistakes and our successes. Seems to make sense, doesn't it? Everyone Knows They Should Do It, But Most Don't Perhaps this does make sense, but software firms don't always seem to think so, according to Alyssa Dver. Dver is vice president of product marketing for a firm named Centerline Software. Centerline sells a product called Acqua that assists software development teams in keeping track of their quality control processes—assuming they have any. Keeping records is the key, Dver says. "If the last time a programmer said, 'It'll take two days,' but it took two years—that's useful data and we should be capturing that." Is that sort of information commonly lost? Dver says yes, it is: "The turnover in many software companies means that there's a good chance that programmer leaves after a year or two, taking that valuable experience with him. A process lets you find problems early on, before the crisis arises. Otherwise, everything seems fine in the beginning of the project, but two weeks before ship time, well, you start to see a lot of beards on the male programmers."8 Centerline conducted a survey in which it asked software firms

Page 51

how they used processes and tracked quality. Part of the survey asked three important questions: 1. Do you have a measurable, repeatable software testing process? Sixty-nine percent said no. It's nearly impossible to imagine any other manufacturing concerns—makers of tires, steel, or automobiles—answering the question in this way. 2. Do you set quality goals? Sixty-seven percent again said no, an odd response in the context of the next question. 3. Do you feel that you can meet quality needs by building testing into the beginning of the development life cycle? Seventy-four percent said yes. "In other words," Alyssa Dver observes, "testing is kind of like flossing—you know you should do it, but most don't." Of course, the problem is that when software companies don't floss, we get the cavities. But it's easy to understand why software companies don't focus more on process and testing—after all, that costs money, right? "Testing is more than just finding defects," argues Alyssa Dver. "Good testing lets you deliver on time, with the functionality that you promised and the quality that your clients need." Unfortunately, her firm's survey shows that most software firms haven't gotten that message. A majority of the software companies that took part in the Centerline survey said that they'd knowingly shipped products with bugs. Unbelievable—this would be like McDonald's adopting a no-sanitation stance, saying, "We know we give some people food poisoning, but we don't make them all sick, do we?" Fully 15 percent of the software firms surveyed said that they didn't test their software before shipping it. Fifteen percent may not sound like much, but how would you feel if 15 percent of the elevators you got into had never been inspected? If 15 percent of the voting precincts never checked for

Page 52

voter fraud? If every Thursday—about 15 percent of the days—no police patrolled the streets? And yet it's business as usual in the software world. Alyssa Dver adds that not using a process can cost a software firm real money in the form of lost clients and opportunities. "Recently, a firm was bidding to build a set-top box for Time-Warner." (A set-top box is a small computer that lets a television do something computer-like, such as surfing the World Wide Web.) "Time-Warner said, 'If you don't have a process, don't bother bidding.' One firm I spoke to reckons that every month they're late to market costs 2 percent market share—and that could determine whether or not they're profitable." Fully 90 percent of developers that Centerline surveyed had been forced to remove a key function from a product in order to ship on time. Fifty-four percent said that having to fix bugs after they ship is the biggest issue in quality, and it's expensive. The developers believed that shipping high-quality software that's been properly tested was the most important thing, and that meeting goals and deadlines was the least important—again, software developers know what is the right thing to do; it's just getting the time to do it. Reasons Why Most Software Firms Don't Use Quality Processes Why then don't companies like Microsoft, Sun, Apple, and the like build some type of quality processes into their software development cycles? "Because their customers are willing to buy crap," says Watts Humphrey. Could it be that these approaches are so new that big software firms just don't know about them? "These process systems have been around for twenty years; it's nothing new," replies Humphrey. So there's probably more to it as well—a clash of culture and method. Or, as one expert put it, "religion." Dr. Frank Ackerman has been a quality assurance manager for several firms, was a staff member of AT&T's prestigious Bell Labs for

Page 53

years, and is now, among other things, an associate with a group called the Institute for Zero Defect Software. Ackerman notes on his home page that his pet peeves are "software bugs, companies that ship buggy software, and people who think that bug-free software is impossible." When asked why Microsoft, Corel, Adobe, or other shrink-wrap firms don't exploit methods that would greatly improve quality at low or no cost, Ackerman says, "It's more a matter of religion than of practicality. They don't believe it. What's ingrained in the managers is, 'This is the way we've been successful, so this is the way we do business.' You'll tell them that there's a bunch of possible techniques, and they'll tell you, 'Well, they don't apply here, or that's only useful on government projects, it makes the software too expensive,' and so on. They just don't have the bandwidth to deal with it. I don't think anybody's come around to them and said, 'If you give me some people and some money to try this, then I'll show you.' Part of the problem is that to make it successful you've got to change the way people think, and you've only got a year—if you can't show businesses results in a year, then forget it. Time has been so compressed in the software business that a year is equivalent to a decade." 9 But what about places like the Motorola plant in Bangalore that's producing CMM level 5 code? Shouldn't that inspire software managers? "You would think so, wouldn't you? But I think there's not a perception of Motorola as a software company— 'They're just some guys in India.' There's been no professional discipline, and everybody kind of learns it on the job. The environment that the manager has grown up in sets [his or her] mind. The speed of the industry is such that the managers don't have time to find out about software quality innovations. If someone just down the street does it, then they're more likely to look into the process." Let's look a little more closely at a process like CMM to see why shrink-wrap firms might not like it. There's no magic to the CMM

Page 54

process, just a bit of methodical procedure. To vastly oversimplify, all CMM suggests is record keeping such as the following: • Estimate how long a task will take you before you do it. Then do the task. Compare how long you thought it would take to how long it actually took. Use that information in planning your next task. • Keep track of things like how many lines of code you can create a day. When you use different coding methods, go back and look over the amount of code created to guide you in separating out which systems work better than others. • Focus more on designing the program and the code right in the beginning than just throwing together a program and testing it. This is hardly an onerous or time-consuming process. Why would a programmer be reluctant to use it? Several reasons, perhaps. Programmers like to invent their own methods rather than following someone else's, and they don't much like being managed—and a process smacks of management. They probably also don't much like the idea of keeping records on their work output, records that others could use against them. Processes also emphasize analysis more than actually working at the computer, and programmers are used to working at the computer. Programmers Prefer To Lead, Not Follow Following processes devised by others doesn't appeal to many programmers, who enjoy—even flaunt— individualistic styles. Part of the hard-core programmer stereotype is quirky eccentricity. Talk to anyone working in a programming shop, and he'll tell you that coming into work at noon and programming until 3 A.M. is quite normal for many programmers. Programmers show disdain and contempt for any kind of dress code—anyone wearing a tie must be

Page 55

"marketing slime." Programming is a tough job, programmers feel, more of an art than a science. Great programmers are called wizards or, in the software quality literature, heroes. 10 In his seminal book Hackers: Heroes of the Computer Revolution, Steven Levy talked at length with programmers and described their world. For those who haven't read the book, the "hacker" label doesn't refer to computer criminals, as it often does when the general media use the term; rather, it refers to an older definition—the most gifted of programmers, the programming geniuses. Levy's book illustrates over and over just how capable these people are—but also ends up spending a lot of time underscoring how idiosyncratic and eccentric these "best of the best" also are. In one story, Levy relates that one such genius, a fellow named Greenblatt, smelled so bad due to a lack of hygiene that his colleagues coined an imaginary scientific unit of smell, or, better, stink, dubbed the "blatt," complete with smaller units called "milliblatts." Greenblatt and his associates also concluded that women just could never connect with programming at as high a level as they had reached, due, they felt, to some genetic difference. People who knew less about computers than they did but who had the temerity to use computers were referred to not as "users'' but as ''losers."11 In the book Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft, author G. Pascal Zachary recounts that a programmer named Walt Moore, assigned to write some vital video driver programs that would enable Windows NT to support a wide array of video hardware, decided that rather than do that, he'd spend his days playing a computer version of a poker game named Pai Gow. Zachary explains, "Moore practiced Pai Gow on his office computer each day. Mastering a game was a hacker thing to do (and Moore was nothing if not a hacker)."12 As a user of Windows NT since its release in mid-1993, I was struck (as were most early users) by the amount of trouble that video drivers presented to NT—install the wrong one, and you'd often have to wipe your computer's disk and reinstall NT from scratch. When I read Showstopper years later, I just

Page 56

shook my head and said, "So that's what happened . ." According to Showstopper, Microsoft's management tolerated Moore's nonproductivity for two years before asking him to move to another project—not to leave the company (although that's what he eventually did), but only to find a different project to work on. How many of us can do little or nothing on a job for two years before our managers step in? The answer is that we all could, if the managers were impeded in managing us—but that's the next topic. Programmers Don't Like Being Managed Part of the developer mythos is that programmers like freedom and chafe at the idea of constraints. Over the years, many Information Systems managers have bought into this notion and accepted it with resignation. Those who've had to ride herd on a bunch of programmers often adopt an attitude of hopelessness about trying to hold developers to the same sort of work habit standards as other employees, saying something like, "Well, you've got to understand that programmers are in general pretty smart people, and intelligent people just don't like being controlled." So in other words, the common wisdom is that programmers don't like having people tell them how to do their jobs and monitor their work to ensure that they're doing what they're paid to do instead of, say, playing Pai Gow. Sure, that makes sense, until you consider that everyone likes freedom from external discipline! Who among us wouldn't like to be free to set our priorities and hours (and while we're at it, why not compensation as well)? Of course, we all would—but we don't get that option. Why are things different for programmers? It's difficult to manage someone performing a technical task that you don't know how to do and the time requirements of which you can't estimate, so it's tough for someone trained only in management and not programming to manage programmers. But that's only half the story; the other part is simply that for much of computing's

Page 57

history, developers have been relatively scarce. There are shortages of programmers in many fields, meaning that those who do have the programming skills often have their managers over a barrel—if the managers don't like their work, the programmers will be happy to leave and go elsewhere, probably for an increase in pay. People Are Suspicious Of Measurement In the early days of factory production, no one knew how best to mass-produce shoes, cars, or light bulbs. How should the factory be laid out? How many steps should the manufacturing process require? What noise, temperature, and lighting levels make the assembly line personnel most productive? No one knew, but the firm that figured out the answer first would have a decisive cost and time-to-market advantage over its competitors. The field of industrial engineering was born in response to the need to know. Industrial engineers would try combinations of different factory layouts, lighting levels, and so on in a set of controlled experiments. They'd monitor the results and determine how best to manufacture a particular product. The key to success was in the monitoring. Without good record keeping, there wasn't any point to the exercise. In the same way, trying different approaches to programming is pointless if there's no way to know what the results of those approaches will be, which means that a process-using programmer must keep records. And there's the rub. Managers—"the suits"—can see those records, and, paraphrasing Detective Joe Friday, programmers figure that any documentation about their work can and will be used against them. Some of that feeling is probably well founded. But managers can't be expected to manage if they don't know how the process is progressing. Most programmers who have ever worked for me have been unable to say at any moment in time how far along they are in their projects, meaning that they don't even have the data to manage

Page 58

themselves. If there's no way to track a programmer's progress, then it's very hard to manage him—he'll blame "uncontrollable external events" for late deliveries, and crow at his "talent" when he delivers something earlier than promised. Of course, those "early" deliveries may indicate less about how talented a programmer he is and more about how untalented an estimator he is. Processes Are Boring The last thing that makes programmers suspicious of processes is that processes emphasize working away from the computer, rather than sitting at a computer debugging. The basic method that programmers use for developing a program goes something like this: lay out what you want the program to do, write an algorithm to do that, convert that algorithm into a computer language, type the resulting code into the computer, and run it. Once it's in the computer, test it to discover undesired behaviors—bugs. Once you've discovered one of these behaviors, go back to the computer code and reread the program to try to find and then fix the bug that created the bad behavior. Nearly everyone who's ever written a program wants to rush over to the computer and type it in and run it—there's a sort of instant gratification that comes from seeing your creation at work, even if it works in a faulty manner. This writethe-code-then-test-it approach is how most commercial software is written. Humphrey and others feel, however, that testing isn't the best approach to producing bug-free code. Suppose Boeing used this method to design airliners. Their designers would draw up a set of plans for a new airliner and, at a cost of millions, Boeing would build a one-of-a-kind implementation of that design. Then they'd see if it could fly and, if it could, they'd see if it could fly under unusual situations—with a few engines out, across the Pacific, in a rainstorm, and the like. Why don't they do this? For the same reason cars and houses and elevators aren't built that way: it's too costly. Humphrey says in "Comments on Software Quality"

Page 59

that "no technologically intense industry, other than software, relies exclusively on product testing to remove defects. It has been known for over 20 years that testing is an expensive and ineffective way to eliminate defects from any product, including software." But old expectations die hard. Drs. Basili and Shelby tried an experiment in support of their Experience Factory research to determine the most effective way of finding defects in a program. They handed some bug-ridden code to students and professional programmers at the University of Maryland, asking them to find the defects. The debuggers used one of two approaches. Some used the traditional method-they'd type in the code and run it to see what it did. Others just reviewed the code "by hand," reading it for design implementation and syntax correctness. Those using the standard testing approach were far outpaced in bug-finding ability by those doing code reviews. 13 Despite those results, however, old programming notions die hard: when asked which approach was better (before learning of the results), 90 percent of the participants said that traditional testing methods were more effective. Answering The Excuses Talk to a software company about why its people don't use quality processes like CMM or the Experience Factory, and you usually won't hear the reasons you just read. Instead of the reasons, you'll hear the excuses: it would cost too much, and besides there's not that much demand or need for low-defect software. Both of these excuses, you'll see, don't hold up well under scrutiny. "It would cost too much" and "People don't want/need that much reliability in their word processor/Web browser/email program" often come together in what I call the space shuttle excuse. I hear this all the time from shrink-wrap software vendors. For example, when talking to Brad Chase, vice president of Internet and Tools Marketing for Microsoft's Internet Platform, after a Microsoft press reception, I asked

Page 60

him if he foresaw a day when Microsoft products would be essentially zero defect or low defect. "What, like medical device software? This is a different market, the whole 'good enough' software idea. You're talking about the computers on the space shuttle with what you're asking." Good enough software, by the way, is a phrase that shrink-wrap folks use a lot. It's a kind of code word. To many people, it means, "Building low-defect software would be expensive, and that would mean I'd have to charge a lot for it, so my market would dry up." The space shuttle came up as a counterexample for reliable software fairly regularly. For example, I asked Netscape's Debby Meredith, vice president of the Client Products Division, "When will software be as reliable as a good meal at a clean restaurant, an elevator, a building?" The first part of her answer was, "Well, you're talking about shrink-wrap software, right? Because things like the space shuttle software or even compilers are very, very reliable. There are less features, and the desire for the feature set to change isn't high." I asked Frank Ackerman of the Institute for Zero Defect Software, "Would good quality cost significantly more?" Not much more, he felt. "If you look at [a firm like] Netscape as a pure software company," he told me, "your actual development staff accounts for about 20 percent of your costs. So suppose we have to double the programmers to produce zero-defect code. As programmers are only 20 percent of the cost, we're only affecting one-fifth of the total cost by increasing the programming staff. It's in the range of 10 or 20 percent overall." In another interview, I spoke with Marc Sokol, senior VP for advanced technology at Computer Associates. He observed, "Software can be made more reliable, as in the stuff the military or [NASA] creates, but it's done with a tremendous amount of belt-and-suspenders. It's not fault-free, just very redundant. That redundancy sort of allows the software to 'self-heal.' "Again, there's that shuttle allusion. But, interestingly enough, when asked how much more reliable software would cost, Sokol didn't feel the need to invoke NASA-like cost figures. "It could cost 50 to 100 percent more in an

Page 61

application [to build in reliability]... .but at present, there are different markets for computer software. The shrinkwrap market is very high feature, lower quality." Meaning that he thought that very few people were willing to pay for higher-quality software in that market segment. If a developer wants to feel better about treating reliability as a low priority, then, the space shuttle is an excellent example to choose. After all, everyone knows that the shuttle is staggeringly expensive, right? What a developer invoking the space shuttle excuse is saying in effect is, "Sure, we could build you a reliable word processor, but it'd cost you $100,000 apiece, and we didn't think you wanted that, so we didn't bother trying." I asked software development guru Ed Yourdon, author of twenty-four books on software design methodology, if he thought a reliable piece of shrink-wrap software would have to cost a lot more money. "[An] amazing thing is that the difference in bugs per lines of code varies by two or three orders of magnitude [from organization to organization]. The average is about one bug per hundred lines of code, which is a staggering number. Good organizations can get it down to the level of one bug per thousand lines of code, and if you've got the resources and the discipline like the space shuttle team, they can get it down to one bug per million lines of code. This can be done with ordinary methods and tools, it's not black magic."14 I followed up by asking, "Isn't that because the space shuttle code is less complex, perhaps smaller than something like Word?" He responded, "Oh, no, I wouldn't think so, but I don't know; my instinct is that the shuttle code is bigger than Word. Processes like CMM can get companies producing three or four orders of magnitude better, and it's not overly difficult. Sure, you can argue that they're spending lots on the shuttle code, but is it really more than all those people paid for Word? I don't think so." Ed's point? Sure, building good mass-market software can cost money, but there are millions of customers to spread the costs around to.

Page 62

It's certainly true that the shuttle's computer system is very reliable and also very expensive to build—no one seems to have an exact figure, but the guesses seem to cluster around a quarter of a billion dollars. But it's not really a very good point of comparison to shrink-wrap software, because of the interesting method that NASA adopted in order to greatly reduce the chance of a computer failure jeopardizing the shuttle's performance. Unsure that a simple process could make the shuttle's computers reliable enough, NASA chose to just put redundant computer systems on the spacecraft. That's no surprise—but what's interesting about these redundant systems is that they were each designed separately. Instead of building a computer program and putting an identical version on five different computers, NASA gave the specifications for the shuttle software to five separate teams and had them write separate programs. Then, when the shuttle needs to do something like calculate orbital information, the separate and independent computer systems all compute the orbital information, and then vote. Hopefully all systems agree, but if they don't, the majority rules. Hmmm ... so the shuttle probably isn't the best project to compare shrink-wrap software to. Let's look instead at another example of reliable space software from NASA, a more recent one. On July 4, 1997, millions of people in the U.S. decided to forgo the fireworks and instead camp out in front of their computers waiting for the first pictures of Mars from the Pathfinder unmanned expedition. The whole project, including design, software, hardware, and boosters, came to $150 million for two systems. Since Mars is several light-minutes away from Earth, Pathfinder's software had to be good, as its robotic rover Sojourner could not be controlled directly by Earth controllers. The best the Earth controllers could do would be to give Sojourner a "places to go" list at the beginning of the day and then let its robotic control program try as best it could to carry out the orders. The software also had to keep track of things like communications with Earth, both receiving commands and transmitting new images

Page 63

back to the home planet. That software also had to help control the Mars Global Surveyor orbiter, placing it just at the right altitude. And how much do you think that software cost to build? $3.8 million. To what do the developers attribute their success and low price? "Smart people and good attitude," project manager Brian Muirhead told me. 15 He also said that the entirety of the Pathfinder code was 155,000 lines, about one-tenth the size of Microsoft Word, according to Dr. Nathan Myrhvold's estimate of 2 million lines quoted in Chapter 1. So how would building clean Pathfinder code relate to building Word code? Well, there are over 20 million users of Word. So suppose Word is about ten times larger than the $3.8 million Pathfinder software. Let's say then that Word cost ten times that, or $38 million, to produce; that would be all of $2 per user. Ah, but a program that's ten times larger than Pathfinder probably costs more than ten times as much to develop. All right then, suppose it's 1,000 times more expensive. That works out to $200 per user of Word, still in the range of what shrink-wrap software costs. But not everyone agrees with that logic. "Pathfinder is just very different from what we do," a manager at one software firm said to me at a conference recently (he insisted that I not use his name or identify his firm). "Different how?" I asked. The manager maintained that the whole process was different, not comparable to shrink-wrap. As he'd just recently been busy deriding the government for its inefficiency, I couldn't resist saying, "So you're telling me that government programmers do a better job than you?" Fighting Unhealthy Software In Health Care Devices And speaking of the government, did you know that there's a part of the U.S. government whose job is to monitor software quality and help software companies produce better-quality software? It's true—the Food and Drug Administration (FDA) does just that. As you'd

Page 64

guess, the agency's scope extends not to the entire software industry, but to a small part of it—the software embedded in medical devices. The idea of bad medical software is pretty scary. The Therac-25 radiation device mentioned in Chapter 1 was a particularly frightening story of poor programming. And it's not the only case of bad software in health care devices—Computerworld reported in its 18 August 1997 issue that a computer-controlled drug pump of the kind used in hospitals ran dry and injected air into a patient, apparently unaware of its empty condition. Have there been noticeable problems with medical software?16 "Oh, yes," says E. Stewart Crumpler, a medical device software expert at the FDA's Office of Compliance in Bethesda, Maryland, just outside Washington, D.C. "There's been problems with ventilators, pacemakers, et cetera, infusion pumps that deliver the wrong amount of a drug. Ventilators are supposed to deliver alarms when they stop working. There are software alarms on the device that are supposed to alert the nursing staff when they fail. This is important because in a ventilator situation the patient is totally dependent on the ventilator to provide their next breath."17 "We are seeing more software problems," Stewart continues. "Have there been deaths and injuries due to software? You betcha." There's less and less of that, however, as medical software is now reviewed by the FDA. "We got started because of the Therac-25 deaths," Crumpler explains. Hearing that, I said reflexively, "Software reviewed by the government? How does that work? Do they watch medical databases? Review spreadsheet programs used by hospitals?'' "The FDA doesn't have anything to do with that stuff," Stewart clarified. "The FDA doesn't regulate all healthrelated software. For example, we wouldn't worry about medical databases. We're concerned with software that controls medical devices, like the controllers for pacemakers, or computer-controlled drug infusion pumps."

Page 65

Still wary of government involvement in the software business, I must admit to thinking, ''Good Lord, Big Brother regulating programmers! What kind of silly bureaucratic rules does the FDA enforce?" To answer that, I turned to John Murray, a coworker of Stewart's. He's a team leader of the FDA's software and intelligent medical devices group and technical advisor to the chief of medical electronics branch area of software engineering. He explains what the FDA wants to see. "We mainly just require that people have a process and that they stick to it. We look at their product specification and look for the safety requirements. Some products don't really pose a hazard, and so we don't really worry about them."18 A process? What process? Some complex, government-mandated set of byzantine rules? "No" John and Stewart chuckle. "Basically, we require that software vendors have some way to test their software, measure how they're doing—have some 'metric' of their performance, so to speak—and that they watch those metrics, that they keep records of them. We don't require any particular approach. If the firm has an approach, and it's something that's going to work, then so be it. Our problem is with firms that don't have an approach, don't have a metrics program so they don't know how good they are. They don't do adequate testing so they don't know how good their product is." So all they're looking for is the same kind of thing that the software process folks we've heard from earlier in this chapter recommend? Yes. Part of testing is regression testing, which essentially means two things: go back and look at how long you thought it would take versus how long it actually did take, and use that as some kind of indicator of how long your next project will take. Once you've done a few well-tracked projects, it gets a lot easier to estimate how long a project will last. Good forecasting means that you're not massively late on some ship deadline, leading to what are called in the business all-night programming "death marches," not exactly a prescription for quality.

Page 66

So doesn't every company making medical devices use a process? When asked about this, John just shook his head. "No, you'd be amazed. I'd guess—not a scientific guess, just off the top of my head—that 50 percent of the firms developing these products don't have a process. You'd be surprised how few people have regression testing, or how many throw away their test cases. You go in and ask them for their testing data and they say, "We can't do that," once you explain what regression testing is. 'We can't do regression testing because we threw away our test cases,' they tell you." Stewart agrees, adding, "Top management doesn't really understand software, and software people have promised way more than they can deliver for too long. We've gotten into a culture of expecting software bugs when we shouldn't have to. Expecting delays or overruns where we shouldn't, and management doesn't know how to change that. We accept the Microsoft approach to validation: send out 50,000 copies and see if it works and, if it doesn't, so be it—we buy it anyway because it's the newer, better thing. It's bigger and better so people just gotta have it. In the medical device area, though, we just can't accept that—you just don't experiment on patients." Returning to John for a moment, I asked him, "Does the quality of shrink-wrap software affect what you're doing at the FDA?" He averred that it did, saying, "Definitely. Bad shrink-wrap software affects all software. The standards that we accept in shrink-wrap software affect the public's general perception of acceptable standards in software. That affects the opinion of the Congress, and they're the ones that give the FDA our direction and mandate." I asked Stewart, "Can the mass market benefit from quality approaches such as the ones you're looking for? Are there things they can use?" Unexpectedly, he doubted it, saying, "I'm not sure they'd want to use it. They're making money, lots of it. Why in the world would you want to interfere with the biggest engine in the marketplace right now? They're doing just fine the way they're doing it."

Page 67

Genius Versus Process Reexamined Are there places where processes like CMM don't make sense? Some industry thinkers believe so. Orthodox methodology doesn't fly with 'good enough' software companies for one reason more than any other: it's boring. Bored people don't work hard. They don't take initiative, and they avoid ambiguous problems instead of tackling them with gusto. Take care to create an exciting environment that fosters responsible heroism, and great software will follow. 19

The writer is James Bach, the chief scientist for Software Testing Labs and a columnist for IEEE Computer, in an article he wrote explaining why shrink-wrap companies don't use CMM or processes like it. The article, "The Challenge of 'Good Enough' Software," is at http://www.stlabs.com/bach/good.htm and is worth reading. But is Bach right? To a certain extent, yes. He argues that the general disdain of "heroes" is misplaced. Bach points out that the inherent disorganization of a wizard is just the kind of thing Tom Peters found so effective in excellent companies and championed in Thriving On Chaos: Handbook for a Management Revolution. A disorganized genius doesn't use some plodding process to create her works, she just works in whatever way feels good to produce excellent programs. That may work for small projects, but can it work for the larger and larger applications that modern requirements demand? Won't even a genius eventually have to adopt some methodology? To understand that, let's take a look at a situation almost all of us have faced where we had to choose between simply relying on innate ability and using a process: studying in school. In progressing through school from kindergarten through Ph.D. work, I noticed something about the students around me. From the

Page 68

very beginning, our teachers preached the importance of good study habits. They told us to take notes, do our homework, and get together in review groups in order to better absorb the information they were trying to teach us. In the first year or two of school, most of us didn't really need to study—they'd show us a new word in reading class, and bang! we'd remember it, no studying necessary. Our brains were like little sponges. By the time we got to junior high, some of us, myself included, still didn't have to study. Everything teachers said just stuck in our brains, at least long enough to be regurgitated at tests. Some students around me, however, started having problems, and many of them decided to develop some of those good study habits. They started doing well again. "Well," we "smart kids" thought cockily, ''they're just not as smart as me," and we continued not studying and doing well anyway. Then I went to college, and all of a sudden things changed. The information seemed to come at me faster than I could absorb it. I found myself falling further and further behind in technical subjects like calculus. Eventually, I looked to some of the others for help. Some had no idea what I was talking about—their brains were better sponges than mine, and they were still able to just sit in the honors calculus class and soak it up without studying. Others looked at me a bit blankly, then asked me how I studied. I had to admit that I didn't study, and they advised me to start. Eventually, I too developed some discipline in studying—forced to do so when I just plain couldn't fit it all into my head. Study habits are nothing more than a process for acquiring and using knowledge. A process-using student takes notes because the resulting written pages reinforce the learning in the brain, and provide backup for later review. A process-using student recopies the notes taken during the lecture because the recopying process lets her clean up notes taken hurriedly and reorganize the information, as well as

Page 69

again providing more reinforcement. Working with companions in a study group makes a student explain concepts to other students, and running one's mouth essentially "lights up" different parts of the brain than writing or listening does. Again, the net effect is that the student now understands the topic even better. Why didn't I develop good study habits in the first place? Partly because I didn't need them, but mostly because they took time. Studying is boring. (Sound familiar?) Doing homework takes time, and seemed less productive than doing something else—at first, anyway. Eventually, however, I had to choose a "less productive" method of knowledge acquisition, or I would have failed in school. Studying is a process that assists a faulty brain in the task of learning. If that was too long-winded an example, here's another example of process versus native ability. At some point in school, you learned to multiply numbers. Part of learning how to multiply required that you memorize the "times tables" every product from 1 x 1 all the way up to 9 x 9. Right off the top of your head, you were supposed to know that 7 x 6 is 42. In other words, you're supposed to develop the "native ability" to remember dozens of products, so you just "naturally" know how to do any one-digit multiplication. But if you want to do a larger multiplication, like 12 x 15, then you employ a process that builds upon your knowledge of one-digit multiplication. Many years ago, however, people had to learn much larger multiplication tables; many people my father's age know right off the top of their heads that 12 x 15 is 180. They spent the extra time to be able to "naturally" solve a larger class of multiplication problems. Even though they've got a larger "natural ability" with multiplication, so to speak, there's no combination of numbers that they can multiply that you can't; you just take a little longer, using the multiplication process you were taught. Now consider what would happen if some people decided only to memorize the results of all two-digit multiplications, and never bothered learning the process for going beyond that? Well, they'd look

Page 70

like real wizards when asked to multiply two-digit numbers, and they'd be much faster than you or me at multiplying 33 x 47. But when faced with a bigger task, like multiplying two three-digit numbers, they'd be stuck. Meanwhile, you could plod along with the one-digit process and eventually get the answer. What's this got to do with programming? Everything. When I first learned to write computer programs in 1973, the first kinds of programs I attempted were small ones consisting of a hundred lines or so of code. Again, I was smart enough to visualize the entire program in my head—the code essentially appeared intuitively in my brain. But that method didn't work worth a darn for larger programs of over about a thousand lines, so I started using other methods. (And I'd never claim to be anything more than a apprentice programmer.) Modern shrink-wrap programs aren't a few thousand lines of code; they're in the range of millions or tens of millions of lines of code. It's no longer possible for one person to understand everything about a major software package like Netscape Navigator, Microsoft Excel, or Corel WordPerfect. Frank Ackerman agrees. "No matter what process you use, they're all basically the same. Software is a very intellectual business, and brains are faulty. The only way that I know of to build reliability into a system composed of faulty components is with redundancy. That's why different people should work on different parts of the software development process. In the engineering world, a designer gives something to a drafter, and the drafter doesn't just mindlessly draw the design—if something doesn't make sense, the drafter asks the designer about it." I've met many programmers for large shrink-wrap companies, and they are in general smart people—very smart people. Microsoft, for example, doesn't really look that closely at a person's particular programming experience when hiring; they look more closely at the applicant's native intelligence. Microsoft looks for people with big "sponge brains," and it's worked well for them. Again, smart people can solve a lot of programming tasks, perhaps very large program-

Page 71

ming tasks, almost intuitively—they don't need a software development process any more than I needed study habits. And for some of those especially gifted people and for some tasks, using a software development process might often take longer than just trusting their capable brains. But as programs get more complex, eventually people's brain capacities are exceeded, and more flawed software results. And building a software industry on smart people is a great idea, but do we really want to have to depend on a steady flow of high IQs in order to keep the industry going? It's hard to convince smart people that a process will help them. James Bach argues in another article, "The Immaturity of the CMM," (it's at http://www.stlabs.com/CMM_AP1.htm, and was originally published in the September 1994 issue of American Programmer), that the innovative nature of the software business is one of its great strengths, and that process models like CMM nowhere mention innovation. But there are really at least two activities going on at shrink-wrap software companies. First, there's the generating of ideas and new directions, goals to be achieved in the next releases of software. Second, there's the grunt work of taking those ideas and making them into actual pieces of reliable code on a CD-ROM. Certainly no one wants to clip the wings of the high-soaring visionaries who come up with the wonderful "big ideas" like the Macintosh as well as the delightful "small ideas" like the autocorrect spelling feature in Word. But implementing ideas is a more down-to-earth task. It is a process-oriented task. Many people believe we need massive innovation in software to produce more "productivity." That's why we need all those new features, they argue—productivity. But there's no proof that widespread computing has indeed made us more productive; in fact, there's evidence to the contrary. Between 1948 and 1973, nonfarm productivity rose at roughly 3 percent each year. Starting in 1973 (coincidentally, the year the first microcomputer appeared in the

Page 72

U.S.), productivity growth fell to a mere 1.2 percent per year.20 The heroes are certainly producing cool new stuff; it's just not clear that it's helping us get our jobs done any better. It's easy to understand why programmers would prefer to be seen as software heroes. They're people doing something that's in great demand and doing it better than the vast majority of the human race. I just don't know that we need heroes writing word processors, spreadsheets, drivers, and the like. Perhaps what we need in those jobs are just ordinary people, people whose goal it is to just get the code working right. The people who turn out quality cars and televisions and houses aren't geniuses, they're just regular people like the rest of us. The way they turn out that quality is by following a manufacturing procedure, a process. Perhaps the heroes should be designing the operating systems of the future—that's an area that needs a lot of thought and inspiration. My guess about why many shrinkwrap firms don't use processes is because shrink-wrap firms still think in terms of hero/geniuses, and it's probably the case that a development team of twenty geniuses would benefit less from the rigor and discipline of a processoriented approach than would a development team of twenty less gifted individuals. But twenty average kids who learn study habits in the sixth grade may well ultimately do better in school than would twenty smart kids who never learned study habits and whose intuitive brains finally met their match during their junior year in college. Perhaps the next version of most major software could do with a dose of average programmers and an aboveaverage process. Many programmers will never come around to the idea of low-defect software. "You will never have bug-free software," an independent programmer declared to me at Microsoft's Professional Developer's Conference in San Diego in September 1997. Deriding the idea, he said, "It is silly to even consider it." Many of his colleagues in the software business agree with him, but there may be signs of a slow change in attitude. "Software with no new features, but zero bugs? It'd never sell," Steve Madigan, Microsoft's senior director of

Page 73

program management for personal and business systems, said to me at another Microsoft Developer's Conference. "Furthermore, you'd have a lot of trouble finding people to work on it. What attracts capable people is the new stuff, the exciting stuff." But I could see Steve mulling the idea over in his head as we talked, however, and a bit later in the interview he reconsidered. "Let me change what I said there," he said. "Yes, maybe there is a market for that. Call it 'hardened software,' 'bulletproof software,' or something like that."21 When interviewing programmers, I hear a lot of that—"Hey, it's impossible [expensive, difficult] to write clean code, so why try, but hmmm, now that I think of it, maybe it isn't impossible." That seems to be the sole barrier between the world as it is today and a low-defect software world: just changing a few minds.

Page 75

Chapter 4 Software And The Law

Page 77

Imagine you are the Information Systems manager at a small company that does computer graphic work—logos, layouts, and the like. You find out that one of your computer-savvy employees is spending a fair amount of time surfing pornographic sites on the Internet when he's supposed to be working. You talk to him, and he agrees to stop goofing off and get back to work. A month later, it's obvious that he's still spending more time on www.hotsex.com than at anything resembling work. So you talk to him again, reluctantly threatening him with disciplinary action. Again, he agrees to stop surfing. You're surprised a few weeks later when you get a phone call from some software industry group asking to come by your office and audit your PCs for illegal software. It seems that they want you to drop everything and go examine the fifty computers in your company for stolen (unlicensed is the term they use) software. Your firm faces several deadlines, so you're not exactly welcoming this task—you pay for your software, and who are these guys, anyway? You tell them you're sorry, but you just don't have the time to do this. The next morning, several men in suits and a federal marshal show up at your door. They have a warrant to examine every hard disk in your office for illegal software—the guys in the suits are the ones that called you yesterday. They close down your office as they run programs to search all of your computers' disks for stolen software. They find lots of software on your computers, of course, and ask you to prove that you own the software. The phones are ringing off the hook because of those clients with deadlines, but you can't do anything about that; you have to prove you own that software. With the help of the firm's accountant, you dig around in the records and find the invoices for the software that you knew you had.

Page 78

It looks like you're in the clear—but then the guys in the suits ask about some financial analysis programs, a few games, a couple of music programs, and a piece of educational software. Huh? It seems there are fifteen different programs you've never heard of and that your firm would have no use for scattered around the office on different computers. You have no idea how they got there, nor what anyone would be doing with them. The people who use those computers look surprised when asked about them, claiming to know nothing of the illicit software. Nevertheless, the programs are there, and you can't prove that you own them. The guys in the suits explain to you that the U.S. laws on copyrights call for fines of up to $100,000 for each and every piece of software found on your computers that you can't prove that you paid for. That comes to $1.5 million. Attempting to make them see reason, you explain that you honestly have no idea how that software got there, that you don't use it, and that there must be some mistake. They reply by suggesting that you put your firm's attorney in touch with them. They then start to impound each computer with the disputed software, boxing up the computers to take with them. But when they come to the computer on the Internet surfer's desk, it turns out that he did indeed pay for the mystery piece of software on his computer. It's his personal copy, and he shows the suits the receipt. They leave his computer alone. A week later, your firm's attorneys come to the company's owner and tell him that the guys in the suits have his firm dead to rights, and that they've offered to settle for only $400,000. They also advise him to take the offer. The owner of the company decides to pay, as he really has no alternative. Unfortunately, the result of paying almost a half million dollars in fines is that he's got to close the company. Like everyone else, you box up your stuff and start making the first of several trips carrying boxes out to your car. On your way out, the surfer offers to help carry a box for you. Out in the parking lot, he muses about how easy it would be to install some programs—

Page 79

copying a few programs to, say, fourteen computers probably wouldn't take more than about an hour's time some day, after everyone else has gone home for the day. He grins at you, gets in his car, and drives away. Sounds like a George Orwell-Franz Kafka collaboration, doesn't it? But it's not impossible. It's something that could happen today under a current U.S. law you've no doubt heard of and will learn more about in this chapter— the Copyright Act, originally designed to protect the authors of things like books, poems, drawings, architectural plans, music, and now computer software. Admittedly, the scenario depicted here is somewhat dramatic and nothing this egregious has ever actually happened. But such a thing could happen and mainly because the softwarerelated laws tend more to protect the software vendors from software users than vice versa. But, as you'll learn in this chapter, that power is not enough for the software industry. Not content with the teeth and claws afforded by the copyright law, software vendors have attempted over the years to convince both us (software buyers) and the courts that they actually possess even more weaponry than other creators of copyrighted works. You'll see that they claim that selling you a piece of software is different from selling you some other piece of copyrighted material, like a book or a music CD. They believe that they can control how you use the software after you buy it through something called a ''software license agreement." You'll read in this chapter how companies like Microsoft have regularly used these software license agreements to quietly raise the cost of software. Vendors' use of software licenses has been ubiquitous in the software business for years, and while many agreements are ridiculously restrictive, the courts have not strongly upheld the enforceability of these license agreements, which has slowed vendors from trying to enforce the sillier sections of their licenses and from writing even more restrictive licenses. But that may change soon, as a group of lawyers is currently seeking to create a chillingly anticonsumer law called the Uniform Computer Information Transactions Act (UCITA), a law so badly flawed that one of

Page 80

the two groups originally charged with its creation has simply washed its hands of the matter and walked away. If passed, UCITA would set in stone forever one simple rule: The software vendor is always right. Copyright Basics Most of us know that theft is bad. For you to sneak into my house, steal my car keys, and drive away with my car would clearly be wrong. If you steal a tangible thing, such as my car, you deprive me of its value—I no longer have the use of that thing. The same would be true of any physical object—any good—that I own or that my business owns. As a result, most societies have laws prescribing punishments for those who deprive others of physical goods. In contrast, there are other kinds of goods that when stolen don't cause an immediate and direct deprivation to the victim; one such good would be an intellectual property, like an idea, a story, or a secret piece of information. We have a number of laws protecting intellectual property; one of those is the copyright law. Copyrights don't protect ideas or secrets; instead, they protect a particular way of expressing an idea. In other words, Stephen King can copyright his particular story The Stand, but he couldn't copyright the basic idea of a population decimated by plague and drawn into an apocalyptic battle of good versus evil. The Copyright Act, a piece of federal legislation also known as Title 17, U.S. Code, is intended to benefit both authors and the public.1 The idea is this: some talented person (the author) creates a work—a painting, a book, a software program, a musical recording. The author owns that work; the work is said to be the author's intellectual property. The author of the work would like to make some money from this unique work, but she can only do that by offering the work to the public. Creating a work and selling it for profit doesn't initially sound all that unusual; how's it different from, say, a baker's job? Well, the baker creates pies, cakes, cookies, and the like and offers them to the public

Page 81

if he wants to make some money. But in this case you, the buyer, can't enjoy the pie or cake until you pay the baker, and once you've eaten the pastry, it's gone—and merely eating it probably doesn't give you enough information to easily copy the pie or cake. The hard part about creating the baked good was needing the oven, the flour, sugar, yeast, and so on, in addition to the baker's talent and knowledge of a recipe. But now consider what happens when you buy a copyrighted work such as, for example, a beautiful poem. You're not really paying for the paper the poem's written on or the ink it was written with; that's a very small part of the value of the work. Further, you could reproduce the poem with very little effort, considerably less effort than baking a pie, cake, or cookie. If you were a dishonest person, it would be very simple to just copy the poem and represent it to others as the product of your own brain. Heck, you might not even have to buy the first copy—you might just look it over, memorize it, hand it back to the author, say ''No thanks," and then start cranking out the copies. With the advent of intellectual property law (IP law, to insiders), however, such an action becomes illegal, protecting the work as the poet's property. Copyright allows an author to state, "I created this," and to control how a work may be reproduced. But it's not just a law for creators—it benefits those who enjoy the work as well. The user of the work benefits because without IP protection, the author might never have bothered creating the work in the first place—why do all that work and end up never making a dime on it when anyone can steal it? Copyright law provides for some strong penalties in the event that it's violated. Photocopy The Stand and get caught, and under the law you could be fined up to $100,000. (Perhaps buying the paperback's a better idea.) Do Copyrights Work? Even though copyright law has been around for a long time, respect for copyrights hasn't really permeated our moral fiber. For many

Page 82

people, copying a CD onto a cassette and giving it to a friend is illegal, but doesn't feel immoral. That sort of attitude makes protecting copyrights difficult. Our American notion of copyrights is not universally accepted around the world, nor has it been accepted in the U.S. at all times. As a developing nation in the nineteenth century, the U.S. chose not to honor foreign copyrights. In a famous testimony, Charles Dickens traveled to Washington to plead with Congress to recognize foreign copyrights, as thousands of schools in the U.S. were teaching using Dickens' writing, but Dickens saw not a penny's compensation for these copies! Now that we as a country are as large a copyright creator as a user, many U.S. firms—software firms in particular—find themselves on the receiving end of Dickensian woes. In 1993, I met Richard Running, an employee of what was at the time WordPerfect corporation, which is now part of Corel. Richard told me with a smile that as far as he knew, there was only one known licensed copy of WordPerfect 5.1 in the entire country of South Africa; but, he added wryly, for some strange reason WordPerfect Corporation got about 50 support calls a day from South Africa. For years, China was one of the worst offenders, having never agreed to recognize U.S. copyrights. At one point, you could walk into a market in Hong Kong and pay just a few dollars for copies of every major piece of software in the world. That's still true in Singapore, where in late 1998 I walked into a store selling CD-ROMs containing Lotus Notes Domino for $15. And if you've never priced Notes, trust me—add a couple of zeros and you're closer to its normal price. Software vendors have good reason to worry about whether or not their copyrights are being violated. The WordPerfect story is replayed many times each day as software is carelessly "lent" from one user to another. I am staggered by the number of big companies and government agencies with what seem to be "copy at will" policies. Many nonprofit firms I've been to seem to think that their nonprofit status somehow elevates them above the need to respect the copy-

Page 83

rights of others. Piracy comes from unexpected corners—I recall talking to an Autodesk executive about an ad campaign the company wanted to do about its market-leading computer-aided drawing (CAD) package AutoCAD. The executive explained to me that "It was great—we'd found this monk that used AutoCAD to design these beautiful stained glass windows. We wanted to use him in an ad... and then we found out he was using a copy of someone else's AutoCAD. A pirate monk! Who would have thought?" I had a smaller version of this happen to me when I contracted with a builder to design and build a house. The builder was hundreds of miles away and I hoped to be able to collaborate with his designer long-distance by sending building diagrams via e-mail. The builder said he'd be willing, but he was skeptical. "You'd have to use the same software that I use," he told me. "No problem," I answered. "Is it one of the 3-D house designer packages? Just tell me, and I'll buy it." "It's pretty expensive, maybe a bit more than you were planning to spend," he replied. "Look," I said, getting a trifle impatient. "This house will cost over $100,000; another thousand or two in design software to make sure I get what I want is a good investment." "It's this package called AutoCAD," the builder explained, as if revealing a trade secret. "Tell you what, let's get a contract to build signed and I'll just copy the program and send it to you." Oh, wonderful, a sleazeball. Might as well have some fun ... "Oh, hey, that's an interesting idea," I said. "How much would it cost, anyway?" "I don't know," he admitted. "I copied mine from a friend." Sigh. Needless to say, I went with another builder. Copying a house you've purchased—hiring a builder to build an identical house without paying the first house's designer a fee for reusing her plans—is a violation of the designer's intellectual property rights. But architects needn't worry too much about such thefts, as

Page 84

first of all, houses are expensive to build, and second, once the design has been stolen, there's evidence sitting around of that theft—the house is right there in broad daylight. Other copyrighted materials, like books, can also be copied, but only with a significant cost in time: it's a pain to lean over the photocopy machine long enough to copy a book, and it takes enough time that anyone with even a minimal conscience will eventually realize that what he's doing is wrong (and, one hopes, stop). Copying software, in contrast, is the work of a few keystrokes and a few seconds' time. As the author of over a dozen successful technical books, I've gotten a lot of pressure to offer my books electronically via the Web or on CD-ROM. I've unilaterally refused for one simple reason: once it's electronic, there's no way to protect it from being copied, although it's worth noting that it appears that a few vendors have come up with attractive ways to put books on CD-ROM and to protect them fairly well. (So don't be surprised if the next book you buy has a CD-ROM version bound into the back cover.) The Watchdogs: SIIA And BSA Copyrights are an effective way of protecting software vendors, but that's largely due to the work of two organizations whose methods of protecting software copyrights are effective, if perhaps a bit overzealous ... but listen and see what you think. Remember the story at the beginning of this chapter? The people in the suits were from one of those two organizations: the Software & Information Industry Association (SIIA, formerly the Software Publishers' Association or SPA) or the Business Software Alliance (BSA). The BSA's largest member is Microsoft, but other large players—Adobe, Attachmate, Autodesk, Corel, Lotus, Novell, and Symantec—are members as well. The SIIA, in contrast, tends to represent the smaller firms. Both organizations were started by software firms as industry groups, "mouthpieces" for the industry as a whole.

Page 85

Both have a number of stated goals of existence, but their main raison d'être is to stop piracy, to protect the revenues of their member firms. As suggested in the previous section, copyright violation doesn't seem wrong to many people. Much of the work of the SIIA and BSA is to change that attitude. Ten years ago, many new PC users were completely clueless about how software is paid for. Sure, it was obvious that if you walked into Egghead Discount Software and wanted a copy of WordPerfect, you'd have to hand about $200 to the person behind the counter. Clearly, some software cost money. But there were some programs that were "freeware," meaning supposedly that the people who wrote the software didn't want any money for it, and "shareware" wherein a software author distributes the software to anyone interested and tells the prospective customer, "Try this software out for thirty days. If you like it, send me money. If not, remove it from your computer." It was essentially software sold on the honor system. The SIIA, founded in 1985, is the older of the two industry associations by three years. It attacks the attitude problem by spending over $100,000 a year on advertising and publicity campaigns designed to get out the word that you can't copy software, unauthorized software copying is illegal, and if you do it they'll catch you. In this, the SIIA has been very effective. In 1995, the SIIA claimed that there was $13 billion worth of pirated software in an industry with over $100 billion in sales.2 The BSA concurred in 1996. BSA president Robert Holleyman told me, "The software industry in 1996 in the U.S. was a $102.8 billion market for products and services. Piracy totaled about $13 billion." While $13 billion is nothing to sneeze at, it's about one-seventh of the size of legitimate software sales. Back in the mid-'80s, many estimates stated that only one out of every two or three pieces of software in use had been paid for. Changing people's minds is one of the hardest things in the world to do, particularly when it's inconvenient for those minds to change. I have talked with many people over the

Page 86

years who see software piracy as an illegal but unimportant act, on the order of speeding, and others who point to Microsoft's profit level (as if that were an excuse) or who whine lamely that they can't afford the software, so they ought to be able to copy it—after all, it doesn't cost the vendor anything, right? In contrast, nowadays it seems most people don't feel that way, or at least they know enough not to voice those opinions, as I hardly ever hear those arguments. This was a very, very difficult thing to do, and the SIIA accomplished it—hats off to them for the excellent work. The other reason the SIIA and BSA exist is because while less software piracy goes on than once did, some still exists. No one knows exactly how much pirate software is out there. About the only available numbers come from the SIIA and BSA, and they've obviously got a vested interest in inflating the piracy statistics a bit—they are member organizations, and if piracy goes away, their members won't need them any more. In much the same way that you've got to take with a pound or two of salt, a Drug Enforcement Agency announcement that $100 million worth of cocaine was seized in a drug bust, the estimate of a bit over $10 billion in pirated software is probably a gross overstatement. But even one-tenth of that amount would still be worth chasing—which brings us to the SIIA and BSA's main job: enforcement. How do the BSA and SIIA get to the point of knocking on a company's door? Kim Willard of the BSA explains. "We've got various programs against counterfeiters, hard disk resellers—people sell hard disks with a 'value added' of software already on the disk—and so-called 'warez' Web sites. But our main program targets business users via fifty-five telephone hotlines worldwide which are promoted via publicity, ads, and the press. "Once a call comes in, usually from a disgruntled employee or ex-employee, our experts decide what action, if any, is needed. If they decide that we should go ahead, we start by sending a letter to the company requesting an audit, which usually is agreed to, and then we decide what should be done based on the results of the audit. Usually

Page 87

it's a request that the company destroy any illegal copies, perhaps pay a fine, and purchase all software that will be kept. If an audit is refused, and we think the matter should be investigated further, we go to the district court for wherever the company is and ask for a warrant for a surprise audit or raid, during which they will be accompanied by federal marshals."3 Basically, the BSA shows up with a federal marshal and closes down a business while running programs to tally up the number of pieces of software on the business's hard disks. It then asks the business to prove that it owns all of that software. If it doesn't, the BSA informs the company that the fines for copyright violation can be staggering— remember, $100,000 per illegal copy. Assuming the person in charge doesn't die of cardiac arrest in the first moment or two, the BSA then settles down to negotiate a settlement. If they catch you pirating, you don't get a stern talking-to; you get to write a big check. There's no second chances. I asked Robert Holleyman, "Given the potential fines for illegal copies, how do you catch people? Don't they just erase what's on their disks after you call them?" "Well, for some companies there's no call, and we simply show up on their doorstep with a federal marshal. We have to get court approval to do that, but we carry out enforcement actions every year where we get court approval to go in with federal marshals and audit the software. And in cases like that there's no requirement for advance notice to the defendant, as they'd just erase the software. Even then, however, we may be able to get a settlement recovery. Even if we provide advance notice to a company, and the defendant erases the software after getting our notice, and if we learn about that information from an informant, then that can be used against the company. The U.S. legal process very much favors discovery. If I've gotten a number of reports that there is substantial piracy in that company, but when I contact that company they report that there is little or no piracy, then if BSA files a lawsuit against that company then we can

Page 88

depose employees. We can ask employees of their knowledge of piracy and what happened to make the pirate software go away—if there was an instruction to the employees to erase that pirated software that's something that would come out in the deposition process." What's the difference, then? How does the BSA figure out who to call and who to just raid? "The facts of the case determine that—the nature of the piracy that was occurring, the information that we have, the information about the extent of the piracy, the motivation of the company, the information about the propensity of the company to clean up their software." I then asked Holleyman why a private organization is doing this. In theory, copyrights are covered under federal statutes, and so a federal enforcement agency like the FBI should be sufficient to protect software vendors' copyrighted materials, right? Only partly right, Holleyman replied. "There are both civil and criminal aspects to copyright law. We mainly pursue the civil side; the criminal side is mainly concerned with people who are doing large-scale copying." So they wouldn't bother with, say, one pirated copy of a piece of software? Holleyman hastens to correct me. "No, that's not right; we would bother. Civil copyright law provides that there can be penalties up to $100,000 per work infringed." The $100,000 maximum fine is based on works—particular copyrighted products—rather than copies. The difference? Holleyman explains. "One copy of AutoCAD could potentially cost the pirate $100,000 plus attorney's fees. The fine for two copies would be the same, as the two copies would be of the same work. If, on the other hand, the second pirated program were [Adobe] PhotoShop, then they could be fined another $100,000. Remember this is all civil penalties; civil penalties are the things that most companies must worry about, because the penalties can be steep and it doesn't require getting a U.S. attorney to bring charges."

Page 89

So the Feds aren't involved because the things that the SIIA and BSA follow are largely civil matters, not criminal matters. Additionally, the BSA and SIIA are concerned not only about copyright violations but the larger issue of software license violations. And, perhaps most important, there's money at the heart of this: you see, the raiding party—the BSA or SIIA—gets to keep a large proportion of the fines, making successful raids a very big financial incentive for the watchdogs. That's how SIIA can afford to pay its president, Kenneth Wasch, $306,000 a year. When a guilty party is found, what does it cost? The BSA Web site contains press releases announcing settlements of $107,871 and $400,000 and $75,000 and $99,611—by mid-October 1997, the BSA claimed to have received more than $6 million worth of settlements from companies, nonprofit organizations, and government departments in 1997 alone. And if you work for a small firm, don't think you're safe. ''Less software piracy in the U.S. means the Software Publishers Association (SPA) [this was the organization's name in 1997, before the name change occurred in early 1999] has fewer big thieves to target, so the group must pursue small and midsize companies instead," reported Kim Nash in "Software Cops Under the Gun," published in the March 24, 1997 issue of Computerworld. Holleyman said much the same to me: "Large businesses tend to be pretty good nowadays, but there's still a problem with medium- and small-sized businesses. That's not surprising, as large firms have both realized that software is an asset that must be managed, and there are also legal risks from unauthorized software. Smaller businesses don't do as good a job because they may not have a dedicated person to manage their IT operations." If you were audited by the SIIA or BSA, what would you need to prove that you own a piece of software? You can usually prove that you own a copy of software in one of three ways. First, of course, an invoice or canceled check will do. Second, every piece of software comes with a piece labeled "Software License," "End-User License

Page 90

Agreement" or the like; that's as good as gold for proving you own a piece of software. Third, it's usually sufficient just to be able to produce the physical media—the disks and CD-ROMs—that the software came on. If, as once was normally the case, the software shipped on a series of floppy diskettes, then the first diskette is usually accepted as proof of license. But what about the hypothetical case suggested in the beginning of this chapter? I proposed it to Holleyman, and asked him if a disgruntled employee could use this to damage his employer. "They could," he conceded, "but I've never seen an example of something like that... I've never seen that, in thousands of cases and seven years' experience. I've never seen a case where evidence was presented that an employee did it simply to try to impose liability on their employer. Most problems fall into the category of sloppy management practices." But, again, it's possible under the current state of affairs. And the informant's identity is kept confidential. Once upon a time, the way a coward could attack someone surreptitiously was by directing the IRS at him; now, there are other avenues. While no one would deny software vendors their right to revenues for products created by the sweat of their brow, software license enforcement has taken on a Gestapo-like feel. Want to screw your employer? Rat to the SIIA or BSA; at minimum, it'll create a panic in the upper ranks when the watchdog calls. In the best (worst?) case, the company may rack up enough fines to be put out of business. And best of all, you're anonymous; the company will never know who destroyed the business and the jobs of all of your erstwhile coworkers. The BSA or SIIA get to wave another scalp in public, and their bottom lines look a bit fatter. In October 1996, the BSA even ran an ad campaign designed to encourage this, entitled "Nail Your Boss." The BSA ran ads in Manhattan with the themes "Blow the Whistle, Report Software Piracy" and "Nail Your Boss, Report Software Piracy,'' according to a BSA press release dated 22 October 1998.4 The press release went on to say that the ads were particularly targeted to appeal

Page 91

to disgruntled employees. Paul Chapman of National Public Radio's U.K. office reported on Morning Edition on 22 October 1997 that the BSA is making a push to find pirates in the U.K., actually offering a $4000 reward for anyone turning in an employer. But suppose we're all committed to staying on the side of right and good (and the copyright laws). Keeping track of proof of purchase for software can be as complex as keeping a set of books or filing taxes. Is that reasonable? ''Just as a company, whether they're large or small, has to spend time determining whether they're in compliance with state corporation laws, tax laws, unemployment issues, so too do they have to realize that there are legal requirements associated with the use of software," Holleyman says. Interesting, the idea that a private firm should have the same kind of power of intrusion as the state and federal governments, the agents of "state corporation laws, tax laws, and unemployment issues." It's frightening to imagine that in the future firms may end up having to retain lawyers with expertise in copyright law in the same way that many companies currently keep lawyers with expertise in tax law on retainer. The SIIA and BSA have done a good job opening people's eyes about piracy. But they haven't helped us stay in compliance very well. And, not coincidentally, they make a large part of their money from people who aren't complying with the terms of their software licenses. Kenneth Wasch of the SIIA echoed that sentiment to Computerworld in the Nash article cited earlier: "Wasch said providing such help to IS shops isn't his job. 'Our central mission,' he said, 'is representing code and content [creators]. Period.' " And how important are bounties to the BSA? The Nash article in Computerworld reported that the BSA's budget in 1995 was $16 million, and a press release on the BSA's Web site claimed that by October of 1997 the BSA had already collected $6 million in fines. That makes fines significant, doesn't it? Holleyman acknowledges this, but presents another point of view. "Look" he says, "obviously we're

Page 92

trying to maximize recoveries ["recoveries" are the fines], but what we're really trying to maximize is impacts on the marketplace. BSA would be doing what we're doing whether we had recoveries or not. What we're really trying to get is growth in the marketplace. We had a very active anti-piracy campaign in Italy in 1993 that tripled the sales in that marketplace—but we didn't get any settlement recoveries from Italy, no money at all. But our member companies sold vast amounts of software because we were successful in driving the rates of piracy down." So does he think he'll manage to eliminate the need for his outfit and the SIIA? "No, I'm afraid not," he allows. "There's still plenty of work to do." Beyond Copyright: Software Licenses While I can't speak for anyone but myself on the matter, it seems to me that the penalties described in Title 17, in combination with the ferocity of the SIIA and BSA, would be more than enough to convince me that walking the straight and narrow, copyright-wise, is a good idea. No, make that an excellent idea. But software vendors want more. They don't want to just keep you from copying their software. They want to be able to control how you use the software. That's led to the notion in the software industry that vendors don't sell you software. Instead, they sell you a license, which is nothing more than a software vendor's permission to use the software, so long as you use the software the way they want you to. For example, inside Microsoft's Office 95, you'll find a piece of paper labeled "END-USER LICENSE AGREEMENT FOR MICROSOFT SOFTWARE." I guess the caps are to get your attention, and Microsoft's like the rest of the industry here—it seems that all licenses start out shouting. In fact, no major software that I know of can be bought, it can only be licensed—at least in the minds of the software vendors.

Page 93

The end-user license agreement—EULA to those in the business—for Office 95 notes right up front that "The SOFTWARE PRODUCT [there's that shouting again] is licensed, not sold." What's that mean? Basically, it means that the software vendor wants to control how you use the software, as the EULA later notes that "... Microsoft may terminate this EULA if you fail to comply with the terms and conditions of this EULA. In such event, you must destroy all copies of the SOFTWARE PRODUCT and all of its component parts." So, in other words, you pay for the software and, if you don't use it the way Microsoft wants you to use it, then Microsoft can instruct you to stop using it—and, of course, you don't get your money back. Is this just Bill Gates flexing his muscles? Not entirely; the termination clause in Microsoft's license doesn't mirror all other licenses, but many vendors also include forcible termination clauses. Just looking at some licenses I have handy, I note JASC's Paint Shop Pro and IMSI's FloorPlan Plus 3D did include a forcible termination clause; Lotus's Ami Pro and Datastorm's Procomm Plus for Windows didn't—but the latter two programs date from circa 1993 programs, while the former two are more recent, so the differences may reflect more about trends in software licensing than in the different approaches of the firms. In what ways do software vendors want to control how you use their products? Here are a few examples. • Virtually every software license I've ever seen tries to limit your ability to rent or lease the software. Some licenses actually claim that you cannot sell or give away the software without the vendor's permission. In other words, I can sell you my old computer but I can't sell you the programs on that computer. Just imagine if booksellers tried this. Libraries wouldn't exist. Used bookstores wouldn't exist. • Many pieces of software for particular vertical markets and for larger mainframe-type machines are sold on an annual basis. You buy the software—oops, I meant you buy a license for the

Page 94

software—and must stop using it after a year. Then you get to buy the latest version of it again and again, every year, even if you are perfectly happy with the version that you've already got and paid for. Imagine if book authors could do this: Webster's could force you to buy a new dictionary every year. The poster shop where you bought your Monet print could come collect an annual "viewing fee." • A few years ago, someone used some of the clip art that ships with Corel Draw to create an objectionable poster and was sued for creating the poster. Corel was named as a codefendant. Corel's response was to require users of its clip art to agree that they would not "create scandalous, obscene or immoral works" using the clip art. 5 • At one time, McAfee's antivirus software's license prohibited you from writing a review of the product without McAfee's permission. You name it, some software vendor's tried it. Whether to deny reviewers their First Amendment rights or to force you to buy software anew every year, licenses mostly add up to the same thing: fewer rights for consumers and more control for vendors. But is this legal? Some experts say no, for several reasons. First, licenses may not apply to shrink-wrap software as currently sold in the mass market. Second, even if licenses are valid, they contain contract provisions that you, the buyer, don't get to see until after you've purchased the software. Third, these licenses, if valid, are contracts of a nonnegotiable nature, "take it or leave it" contracts, and such contracts are often unenforceable when applied to mass-market, consumer-type transactions. Licenses May Not Be Valid As you've read, shrink-wrap software firms claim that they don't sell software. Selling software would let you do anything that you wanted

Page 95

with it, so long as you didn't violate the firms' rights under copyright law—you license it. But IP experts don't all agree that the firms can legitimately claim to be licensing software when it appears that they're selling it. One such expert is Cem Kaner, a prominent lawyer, consultant, and consumer advocate in the software license and quality worlds. Cem has done many things in a long career in the computer business, but the short version of his resume is that he's a person who's spent over twenty years working to try to make computers more useful. With a B.A. in mathematics, a Ph.D. in experimental psychology, and a degree in law, Cem advises software firms about quality and the law. He is the coauthor of the second edition of Testing Computer Software (International Thomson Computer Press, 1993), a premier title in the software quality field, and Bad Software (Wiley, 1998), an indispensable handbook on your legal rights when dealing with buggy software. Cem is also one of the few lawyers I've ever met who can explain the law in terms understandable by the average person and make it make sense. I always walk away from a conversation with him thinking, "Now if he'd teach law school, I'd enroll in a heartbeat." Cem explained to me that a software company's wanting to control what you do with their software after buying it is nothing new; other industries have made similar attempts to control their products after sale. In the early part of the twentieth century, for example, books were sold with a "license" that said, "This book cannot be sold for less than $1." The regular price of the book was $1, so the effect of this would be to kill the used book market. The United States Supreme Court threw out this clause and several other attempts to limit use or resale of mass-market products. "This 'you buy a license, not the product' idea is so old and has been tried by so many industries that it's like a tired rerun on TV. This is the Gilligan's Island of sales practices," Cem says. Kaner's not the only lawyer who feels this way. Professor Ray Nimmer of the University of Houston explained the difference

Page 96

between a license and a sale that calls itself a license in this quote from his well-regarded 1992 text called The Law of Computer Technology (pp. 1-103): Ownership of a copy should be determined based on the actual character, rather than the label, of the transaction by which the user obtained possession. Merely labeling a transaction as a lease or license does not control [emphasis added]. If a transaction involves a single payment giving the buyer an unlimited period in which it has a right to possession, the transaction is a sale. In this situation, the buyer owns the copy regardless of the label the parties use for the contract.... The pertinent issue is whether, as in a lease, the user may be required to return the copy to the vendor after the expiration of a particular period. If not, the transaction conveyed not only possession, but also transferred ownership of the copy.

So Professor Nimmer is saying that if you go into a store, give the guy behind the counter some money for a copy of software, take it home and use it, and never interact with the company who created the software again, then you didn't license that copy, you bought it. So why do software vendors get away with it? According to Kaner, "Very few courts have been asked to rule on license provisions. But if [UCITA] passes, they won't have to—software licenses will be the law of the land." You'll read more about UCITA later. License To Steal: Hidden Contracts Suppose some court or new piece of legislation says that shrink-wrap, mass-market software sales are indeed licenses rather than purchases. A license is just a kind of contract; is that contract valid? Possibly not, as these "contracts" are often a secret until after you sign them.

Page 97

"Try calling a software vendor to see what his software license says," challenges Todd Paglia, the staff attorney for Ralph Nader's Consumer Project on Technology. Todd's an important part of keeping the law concerning buying software oriented toward consumers, and you'll hear more from him later in this chapter. He explains, "We thought it would be a neat idea to collect all these different license provisions into a single survey—but we simply could not get the retail vendors of the software to send us copies of their license agreements, nor could we find the license agreements on vendors' Web sites."6 I accepted his challenge, and Paglia's right—a look at twelve software vendors' Web sites showed that while they all feel that their software is licensed, not sold, they're not about to show you the license until after you buy the software. Ever installed a piece of commercial software? Then you've probably seen a "post-sale disclosure of terms." You go to install a piece of software and all goes well for a few screens. Then it pops up a long legal-looking thing requiring you to agree to its terms if you want to continue installing the software. One it-would-be-funny-if-itweren't-so-sad example appears when you try to install Microsoft's NT operating system; it shows you the license agreement and forces you to look at every single page of the agreement before allowing you to click "I agree"—and yet about a third of it is in French, which for some reason most NT users don't speak. (I don't know French, but I think I saw something about first-born children.....) In other words, you spend hard-earned money to buy a software product. You take the time and trouble to have it shipped to you, or else you drive out to a store to pick it up. You set aside time to install it on the computer ... and surprise! it springs some contract on you. Some contract with terms of varying ridiculousness. Do you have the option not to agree? Sure, but now what do you do? Box it all up, drive back to the store, and try to get them to take the product back and give you your money back? Many of us would just say, "Ah, the heck with it," and just put the software on the shelf. Result: the software vendor

Page 98

wins—he's got your money, and doesn't even have to produce anything, as you never actually run the software. Here's another example of how post-sale disclosure of terms is unreasonable. You may know that there are a great many applications, generically called utilities, whose sole purpose is to allow you to maintain a PC or diagnose problems. For example, whenever you install new RAM into a computer, it's a very good idea to run a stringent diagnostic program to test the reliability of this new RAM. Another example would be a program that lets an expert recover data on a damaged hard disk. These are special-purpose tools that you'd use only infrequently and rarely need more than once on a given computer. You'd think you could carry these tools around on a floppy disk or CD-ROM and just use them on a computer as needed. But the first time you install the software, the license pops up, telling you that you can only install this on one and only one computer. In other words, you get to shell out a hundred or so bucks for every computer that you want to test or repair—essentially a one-shot repair fee. This is silly. Can you imagine buying a screwdriver and being told that you can only use it to tighten one screw? Or, more in line with this discussion of post-sale disclosure, can you imagine buying a screwdriver packaged in an opaque box, taking it home, opening the box, and then finding out that you could use it for only one screw? Both cases are unreasonable, although the latter is more so. And yet this issue of how many people and PCs can use a single copy of software is the one thing I've seen in every single software license. Because it's in the license, the answer to the question, "How many machines can I put this software on?" is—you guessed it—only answered after you buy the software and the shrink-wrap license terms are revealed. It's worth making a short digression here into this how-many-copies-can-I-make question to highlight a case study in craftiness: the way Microsoft used its licenses to quietly raise the price of its Office suite of software.

Page 99

License To Befuddle Suppose your company buys Microsoft's Office suite, a package including a word processor, spreadsheet, presentation program, and e-mail client/personal information manager. The company has issued you a laptop and put a computer on your desk at work. You also own a personal computer of your own at home. That's three computers—the one at work, the laptop, and the one at home—and one person, just you. How many of these machines can you put Office on? It depends on which version of Office you use. The Microsoft Office 95 license says that you may "install and use one copy of the SOFTWARE PRODUCT ... on a single computer. The primary user of [that] computer... may make a second copy for his or her exclusive use on either a home or portable computer." So you can put one on the machine at work, and then either on your computer at home or your laptop, but not both. Many people object to this kind of license, arguing that so long as you're not using two computers at the same time, what difference would it make how many computers you've got a piece of software on? (This presumes that while you're at work, no one's at home simultaneously using the copy of Office back on the home machine.) If you didn't like that license, look at Office 97's, which no longer even gives you the option to put a copy on your home computer, now offering only a copy on a "portable computer." In contrast, the license for the version of Office before Office 95, Office 4.2, allowed you to put the software on all three—home computer, office computer, and laptop. (Office 2000's license is the same as 97's.) What a shame that the industry doesn't agree on the license used by Borland International years ago. Called the "No-Nonsense License Statement," it reads: "... You must treat this software just like a book ... [which] means, for example, that this software may be used by any number of people, and may be freely moved from one computer location to another, so long as there is no possibility of it

Page 100

being used at one location while it's being used at another... or by more than one person... at the same time.'' A logical and commonsense approach, but not one used all that often. Other vendors use a per-user license, a type of license that associates a particular copy of software with a particular person rather than a particular computer. Under a per-user license, you could install a particular copy of a piece of software on as many computers as you wish, but only you can use that software—no sharing with others! The most popular approach to software licenses is some variation on the Microsoft theme. Every workstation (PC, Mac, or Unix computer) in a company is basically assumed to "belong to" or be associated with one person. That person can put a copy of the software on his workstation, and perhaps a laptop and home computer. While the license seems person oriented, recall that the person cannot take along the software and install it at will—its "home" is on that person's workstation. This type of license is, then, often called a per-workstation license. Yet another approach is a concurrent license, which is very similar to the Borland approach. Under a concurrent license, you need only buy the maximum number of copies that will be active at any moment in time. For example, suppose Acme Industries wants to buy enough licenses so that everyone in the firm can use BugWord, a mythical word processor from a software vendor offering concurrent licenses. Acme has 1000 machines and 950 employees (the other machines might be in generally available areas), but due to multiple shifts no more than 400 employees ever use BugWord simultaneously. Acme need only pay for 400 copies of BugWord. Concurrent licensing is very attractive, but is usually only available to larger companies: for example, until recently Microsoft offered concurrent licenses for Office to large companies. But concurrent licensing is disappearing; as I was writing this book, Microsoft announced that it would no longer offer concurrent Office licenses.

Page 101

Years ago, many licenses were per user, now, more and more, they are per workstation. Why do software firms do that? Well, think about the scenario in the beginning of this chapter. A one workstation, one license policy makes it very easy to break down a business's doors, count the number of copies on hard disks, equate hard disk copies to licenses, and start levying fines. Concurrent licenses require some kind of program to do software metering, which would make collecting copyright fines harder—the software police would have to get into the records of the software metering program and hope that they weren't manipulated by the suspected violators. Microsoft's action of tightening the restrictions of the Office license from version 4.2 to version 95 to version 97 is an example of how software vendors use the license—quite literally, the fine print—to introduce hidden price increases. Businesses considering upgrading from Office 95 to Office 97 will plan for the cost of buying the updates, but they probably won't realize that if they want their employees to continue to have access at home to the same software as the office, they'll have to buy a whole lot more new copies—one for each employee who might at some point do some work at home! Even worse, you have to wonder how many businesses never even noticed the license change, and are in violation at this very minute. I am a regular keynote speaker at technical conferences and I often tell the 4.2-to-95-to-97 Office license story, invariably to shocked expressions on the audience's faces (and a high percentage of the people in the audience are often IS managers). To this day I have never met anyone who knew about the changes in license terms. And this isn't the first time Microsoft has done something like this; the last time I recall was when they updated Windows 3.0 to Windows 3.1. The Windows 3.0 license allowed business users to also run the same copy of Windows 3.0 on their computers at home; the Windows 3.1 license did not, another very expensive hidden cost.

Page 102

The Dangers Of Postsale Disclosure Not to beat this subject to death, but let me make a few more points about post-sale disclosure before moving on to the third concern, the take-it-or-leave-it nature of software licenses. The main objection to post-sale disclosure is that it's inherently unfair. Software buyers are asked to buy a pig in a poke. Software vendors' reply that, ''Well, you can always return the software if you don't like the license," is disrespectful and meretricious nonsense: there are nontrivial costs to returning software, and no one's about to reimburse you for those costs. Secondly, it's sneaky. Common sense tells you that if I don't let you see something before I sell it to you, chances are good I'm hiding something. I've asked a number of lawyers both for software firms and for the software industry associations why licenses are hidden before sale, and I've never gotten a straight answer. "Vendors will begin revealing license terms pre-sale, don't worry—it'll happen automatically through the competitive process," they airily say. Really? The software business is getting more competitive? Since when? We just don't do things like this in most industries: how'd you like to buy a car, only to find after you've purchased it that it comes with no more than a 15-day, 200-mile warranty? Well, fear not, it won't happen—a law called the Magnusson-Moss act prohibits it. Unfortunately, that law doesn't refer to software. Perhaps other industries can benefit from this novel extension of contract law. How about shrink-wrapped produce? Instead of seeing produce in bins as you do now in supermarkets, you instead see small brown plastic bags on a rack labeled "lettuce," "onions," "oranges," and so forth. Say you pick out a bag labeled "lettuce" in anticipation of making a salad. You're not allowed to open the bags until after you leave the store, of course, and once you open the bag you find the produce, a license agreement, and a plastic display card with the name

Page 103

of the grower printed on it. This agreement says that by opening the bag, you agreed to many things. First, you agree that only one person will eat this produce; if you intend to feed more than one person, you'll need to purchase a "bite license" for each person. You are, however, allowed to let others admire the attractive lettuce—that's what the display card is for. Second, you agree that you will put the display card prominently near whatever dish you have created with the lettuce, so that others will be able to easily identify the grower of this wonderful lettuce. Third, as the grower cannot be responsible for how his produce is handled once it's been picked, you agree not to even try to sue him even if the produce is rotten or bug infested. But, it's reasonable to ask, shouldn't software vendors have the right to determine the terms under which they sell their product? Jamie Love, director of Ralph Nader's Consumer Project on Technology, argues that draconian software licenses attempt to take the power to spell out the terms of a sale away from the consumer protection laws and into the hands of the software vendors. That concerns Love because, as he observes, "It's the difference between letting state legislators and judges decide what the consumer's rights are and letting the software companies decide what those rights are." He goes on to explain that "The software companies want the license to control the entire nature of the business transaction; that's what's wrong with it. It's like being able to write your own Constitution and federal and state statutes by contract. It's the difference between having state legislators and judges determine what the consumer's rights are and letting the software vendor do it. Imagine dealing with an airline and losing your bags, or getting bumped, or being rerouted without warning. Would you rather have your protections there defined by the law, or the FAA, or the fine print at the bottom of the ticket? What makes you more comfortable?" Cem Kaner agrees, saying, "Given the abuses that we've seen from software publishers so far, I think that they have demonstrated that Jamie is right."

Page 104

Are Software Licenses Contracts Of Adhesion? Okay, let's assume that software is sold as a license rather than an outright sale. And let's assume that post-sale disclosure is reasonable. There's still something a bit fishy about software licenses. They're contracts you can't negotiate. If I write a special piece of software for you and we agree that you'll only use the software on a particular computer, use it only on Fridays, not tell anyone about it, and stop using it in eighteen months, that's perfectly legal—and reasonable. You and I can agree to all kinds of things, so long as we both have agreed to enter into a contract, we're both capable of making a contract—that is, legally competent, adult, and not under the influence of drugs or coercion—and we both understand what we're agreeing to before signing the contact. 7 Therefore, a software license in a case like that is perfectly legal, and if you violate it, most judges will side with me. In contrast, shrink-wrap software licenses probably fall into a category called contracts of adhesion, defined as "a standardized contract, which, imposed and drafted by the party of superior bargaining strength, relegates to the subscribing party only the opportunity to adhere to the contract or reject it." 8 In other words, you, an individual, want to buy a piece of software from some big company. The big company says that you don't really buy the software, you buy the right to use it subject to some contract, the license provisions. So a contract, a bargain, must be struck between you and the software vendor. The license is that contract. But there's no negotiation, nor the option of any. Offering a consumer a take-it-or-leave-it contract may result in a contract of adhesion that a court won't uphold. A court may strike down a contract of adhesion for one of two reasons. The first is that the provisions of the contract fall outside of the reasonable expectations of the weaker party, or the provisions are "unduly oppressive" or

Page 105

"unconscionable," even if the contract is within the expectations of the weaker party. In other words, you can't offer a starving man a ham sandwich in return for lifelong servitude; even if he does accept the sandwich, you can't hold him to the agreement, as the terms were unduly oppressive and unconscionable. Will a software vendor negotiate the terms of the license agreement? Not that I've ever seen. Software firms have modified their agreements when selling software to large government agencies or big private enterprises, but I've not heard of it happening elsewhere. And nowadays the installation program for many pieces of software shows you the text of the license agreement on the screen, and then refuses to continue installing the software until you click a button labeled "I agree to the terms of this license"—sounds kind of adhesive, doesn't it? Fixing Software Licenses Let's suppose now that all of these objections have been swept aside. Assume that software is licensed and that current software licenses are valid, post-sale adhesive nature and all. I hope that's not the case, but let's consider the results, were that to happen. If the SIIA and BSA truly want to see people comply with software licenses and to respect copyrights, why don't they as industry groups work with their members—Lotus, Microsoft, Autodesk, Corel, and others—to make it easier for all of us to "stay clean?" In particular, they could make more uniform how licenses work vis-à-vis users and whether we're allowed to put copies on other machines for a particular person's convenience. The industry should unify the provisions of software licenses, most specifically in the areas of how the licenses are allocated and what machines can contain copies of a piece of software. First, all licenses should be concurrent: you buy X copies and ensure that no more than X people use the software at a time. Software is an intellectual good like magazines, videotapes, or books, and we've essentially had concurrent licensing for those items for

Page 106

years. Concurrent licenses can be tracked by putting the applications on a central network computer and requiring users to run the software from that machine, which can then meter the number of people using the software at any given moment. Alternatively, if a firm doesn't use a network, or if networking doesn't make sense (laptop users clearly can't benefit from networked software when they're away from the office), then the software buyer should have the choice of buying a per-user or per-workstation license. The current system of software licensing requires keeping track of which licenses are per user, per workstation, and all the other possibilities in between. Keeping track of those licenses is very labor intensive and prone to error—error that, if discovered by the software storm troopers, is costly. In the same sense, vendors should stop playing games with the "extra machine" rules. The provisions of licenses saying whether you can install a piece of software not only on a machine at work but also on a laptop and perhaps a machine at home are, as we've seen, implemented in many different ways—too many ways. Worse, these licenses have been used to quietly increase the price of software, as you've seen in the case of Microsoft Office. Again, a concurrent licensing scheme makes the most sense and is fairest. If your company (or household) is going to buy a piece of software, the answer to the question, "How many copies will I need to buy?" should be that the number of licenses you must buy equals the maximum number of people who will be using the software at any moment in time. It doesn't matter if your company has 1000 employees and 2000 machines; if no more than 57 people will use the software at any given time, then you shouldn't have to buy more than 57 licenses. The idea that one person needs to buy three copies of a piece of software—one for the office, one for home, and one for the laptop—is as ludicrous as saying that this book has a "location license," according to which you, the purchaser of this book, must read this in one designated room in your house. If you plan to read this in another room, at your office, or while commuting on the

Page 107

bus, then you must buy a copy for each one of those locations. (Oh, and by the way, you agreed to the terms of this license when you opened the book, and don't expect McGraw-Hill to negotiate those terms....) That's the problem: Software vendors have created a set of software license provisions sufficiently complex that many people are probably in violation without knowing it, despite good intentions; doing one's taxes can sometimes be simpler than calculating the number of licenses needed to "stay legal" with a particular piece of software. The licenses didn't become complex for any evil reason; they were just a reaction to years of lost revenues from piracy—but the fact remains that they are complex. The vendors then created an enforcement arm (the BSA and SIIA) whose initial job was to heighten awareness of vendors' rights, but whose effect more and more is simply to penalize firms who can't afford a full-time person to oversee their software licenses. A better role might be in assisting firms with remaining in compliance, but as the above quote from Ken Wasch underscores, the SIIA doesn't see that as its role. I asked Holleyman if compliance would get easier. He said that it was. "It's getting easier now for two reasons. First, networks make it easier for companies to employ metering and counter schemes so they can control who's using an application from the network. And second, it's easier because there are prototypes out there for responsible software management." Holleyman allowed that managing software licenses isn't a simple job for a company. "This can't be managed in a willy-nilly fashion. There has to be a clear management procedure to deal with it." Court Decisions About Software Licenses If software licenses are on such shaky legal ground, what have the courts said about those shrink-wrap licenses? Not much, unfortu-

Page 108

nately. There have been only four significant cases in reference to shrink-wrap. Truthfully, none of these cases really presented the court system with an opportunity to clarify what is and isn't acceptable in licenses, but they're the current case law. This quartet of litigations is known as Step-Saver, Vault, ProCD, and Gateway. Step-Saver In the late 80s, a company named The Software Link offered a program called Multi-Link that it claimed was just like MS-DOS, the main PC operating system at the time, but with the added bonus that it could multitask, which means that you could put Multi-Link on your PC and run several programs at the same time. That's common nowadays—Windows can easily do it—but at the time Microsoft did not offer a multitasking version of MS-DOS. Unfortunately, MultiLink wasn't 100 percent MS-DOS compatible, and so didn't always work. A firm called StepSaver Data Systems bought Multi-Link and found it useless. Step-Saver wanted its money back, and The Software Link refused, citing that right on the top of the box it said that the software was sold as is, with no warranties at all, and that anyone who didn't like that should return the software unopened for a refund. In other words, The Software Link was saying to its customers, "You are only allowed to use this software if you agree that this software doesn't do anything. Don't expect anything from it. If, on the other hand, you expect this software to do something, then you're not allowed to use the software. Oh, and by the way, the simple action of opening up the software's box is the same as signing on the dotted line—you've indicated that you agree to the terms of our contract by opening the box." The Software Link claimed that Step-Saver could not sue on the basis of the contract. Sound a bit like postsale disclosure? The court thought so, and allowed Step-Saver to sue The Software Link.9

Page 109

Vault In another case, Vault v. Quaid, Vault was a company that built and sold copy protection systems, methods of making it difficult to copy a floppy disk. The idea behind these is that if I want to sell you a program but also want to keep you from violating my copyrights to the program, I can do some kind of sneaky trick to make the floppies impossible to copy. Quaid Software Ltd. built a program called RAMKEY that made it simple to circumvent Vault's copy protection system. The case had a lot of pieces to it, but the interesting part is that the court ruled that parts of the shrink-wrap license were invalid because its terms were too restrictive: Vault's shrink-wrap license said that you couldn't load the software into memory. What good is software that you can't load into memory? Well, what Vault really meant was that you couldn't load it into memory for the sole purpose of trying to figure out how to circumvent it—but the court pointed out that directing a buyer of a piece of software not to load it into memory was unreasonable, and so the software license was a contract of adhesion. ProCD The most recent case, ProCD Inc. v. Zeidenberg, upheld the provisions of a shrink-wrap license, but only on appeal by a Judge Easterbrook. ProCD is a firm that compiled a list of telephone numbers, names, and the like, and put this list on a CD-ROM. The CD-ROM included searching software—basically, it was an inexpensive database of information on people in the U.S. The license said that a customer was able to use the database as much as she liked, but not to resell the information in the database. ProCD claimed that it cost them $10 million to compile the database. One buyer, Matthew Zeidenberg, had a firm named Silken Mountain Web Services. Someone could log onto Zeidenberg's Web site and do database searches on the telephone

Page 110

information on the ProCD database. In effect, Zeidenberg had hooked the ProCD database up to his Web site, and was essentially reselling ProCD's database. At first, the federal district court in Wisconsin ruled that ProCD's shrink-wrap license wasn't enforceable because Zeidenberg couldn't read the terms of the contract before buying the product, a normal state of affairs in shrinkwrap products. But the federal court of appeals for the Seventh Circuit reversed the district court ruling, an important win for shrink-wrap vendors. The court zeroed in on the question of whether contracts that the buyer can't see beforehand were valid. The appeals court decided that such contracts could indeed be valid, and were valid in the case of things like consumer product warranties, airline tickets, and concert tickets. The court felt that as long as you had the option to get your money back if you didn't like the terms of the contract, then hiding the contract prior to agreement was okay. Gateway Easterbrook later added another major judgement in favor of computer companies, Hill v. Gateway 2000, Inc. (1997.C07.7, United States Court of Appeals For the Seventh Circuit). The Hills bought a computer from Gateway 2000 and ran into a problem with it several months after receiving it. They tried to get satisfaction from Gateway, but were unhappy with Gateway's response. They tried to sue Gateway, but were told by Gateway's lawyers that the sales contract for the computer required that any disputes go to arbitration rather than court. The Hills said, ''No one ever told us about that when we bought the computer," but there was a piece of paper in the box with the computer that said, "Here's your contract, if you keep the computer for more than thirty days you agree to this contract." The law about software licenses is, then, slowly coalescing out of several court cases. That's unfortunate, as the four cases that are

Page 111

shaping software license law are pretty extreme. The Software Link's assertion that it's okay to sell a product and to force the customer to agree that the product doesn't actually have to do anything is ridiculous on the face of it, and it's hard to imagine a major software vendor writing a license that is so extreme. The Quaid case is a bit limited as well, as it was really more about someone's right to dissect (the industry term is reverse-engineer or decompile) a piece of software. Unfortunately, the court of appeals chose to make a sweeping ruling rather than restricting itself to a more specific judgement, and, at this writing, it is the most recent law concerning shrink-wrap software. The Gateway case, while not a software case, upholds post-sale disclosure.10 (Thanks so much, Judge Easterbrook.) Carving Licenses In Stone: UCITA On 7 April 1999, two major law-drafting associations, the National Conference of Commissioners on Uniform State Laws (NCCUSL) and the American Law Institute (ALI), announced that NCCUSL would propose a new body of law called the Uniform Computer Information Transactions Act or UCITA to each of the fifty states. It is, of course, big news when a new body of law is sent along to legislators for their consideration. But, as is often the case, the really big news wasn't what the press release said; it was what it didn't say. You see, the press release was issued by both ALI and NCCUSL (and I'll explain more about them in a bit) and said that NCCUSL would propose this new UCITA—so why was ALI a co-issuer of the press release? Simple: because what was christened UCITA in April of 1999 was actually a renamed version of a law called UCC article 2B that both ALI and NCCUSL worked on together for nearly eleven years. The unspoken part of the press release, then, was that ALI had chosen to have nothing to do with UCITA, essentially disowning the law. This is almost like the U.S. House of Representatives telling the U.S. Senate, "We don't need you—we'll write our own legislation from now on."

Page 112

It's a stunning break for two organizations that, as you'll see, have worked together since 1923 to ensure that the laws of the fifty states are uniform and logical. But the American Law Institute was, at this writing, only the most recent in a long line of organizations decrying UCITA. The Birth Of UCITA: Uniform Codes And Article 2B When traveling from state to state, we expect that the rules will be about the same: businesses all accept the same kind of dollars and credit cards, bathrooms have to be about equally clean in restaurants in all fifty states, and there's supposed to be at least a grain of truth in the advertising we see. Sure, a lot of little things vary, like whether you can buy liquor on Sunday (or at all), but in general we expect all of the ''united" states to act united. It hasn't always been that way. Some laws are federal laws, and so of course are observed in all of the country. But much of the law concerning how consumers and businesses interact is state law, and there's no legal requirement that all states follow the same rules. If they don't, however, it can be kind of confusing—and through much of our history, the rules for doing business varied from state to state. In 1889 the American Bar Association decided to try to influence the various state governments to unify some of their laws. The effort was successful: there are now several "uniform codes" between the states. Perhaps the most important is the Uniform Commercial Code, or UCC. Work began on it back in 1940; it wasn't completed and adopted by all fifty states until 1968.11 The UCC regulates how people do business in nine areas, each called an "article." One of the most important is Article 2, which regulates how to sell goods. It's not clear if information and information-related products are a kind of good, so a number of interested parties have been working for the past eleven years to change the UCC to

Page 113

make it more relevant to today's cyber-economy. In the process, they defined a proposed new subarticle to the UCC called 2B that controls how to sell intangible goods, of which software is the most important. 2B is what NCCUSL renamed UCITA in April 1999.12 The Mechanics Of The UCC Amendment Process UCC 2B started life in the same way as all proposed amendments to the UCC. There are two nonprofit organizations of lawyers from around the country that develop a set of proposed changes to the UCC. The changes then go to each of the fifty states, and then each state government makes the changes to that particular state's business and commerce laws. There's no law compelling states to adopt the proposed changes, but the UCC has had a pretty successful record of getting its proposals adopted. As Todd Paglia, staff attorney to Nader's Consumer Project on Technology (he works with Jamie Love), explained to me, "The state legislatures get a two hundredpage package of proposed changes to the laws and they don't have time to examine them in detail," so the changes tend to get passed as a package. The two organizations that draft changes to the UCC are the American Law Institute (ALI) and the National Conference of Commissioners on Uniform State Laws (NCCUSL, pronounced nack-yoo-zal by UCC literati—ALI is just spelled out as letters rather than pronouncing it alley or something like that). ALI was created in 1923 with the intention of making laws easier for lawyers to understand (too bad there aren't things like that for the rest of us) through "restatements" of the law, essentially Cliffs Notes for various sections of the law. Ed Foster is an editor at InfoWorld magazine and has been following the 2B/UCITA process in print; as he explained it, ALI is "kind of the proofreaders of the legal industry, they deem 'is this well written, logical, is this good law?' "

Page 114

The other deliberative body, NCCUSL, started in 1892 with the intention of creating uniform laws across states and territories of the U.S. NCCUSL works alone writing most uniform codes—in addition to the Uniform Commercial Code, there are others like the Uniform Partnership Act and the Uniform Trade Secrets Act—but with ALI to maintain the UCC. Before a change can be presented to the fifty states, both NCCUSL and ALI must approve the proposed changes at their annual meetings. The entire NCCUSL and ALI organizations don't do most of the debate and consideration required to create a new or modified law; that's given to a drafting committee headed by a reporter. The reporter, the only paid member of the drafting committee, has a tremendous amount of clout in deciding what does and doesn't go into a proposed UCC change. 2B's reporter is Professor Ray Nimmer, from the University of Houston's law school faculty and the author of the book on software law quoted earlier in this chapter. Normally, NCCUSL's reliance on experts like Professor Nimmer and ALI's insistence on well-written law work together to create good uniform laws—so good, in fact, that some other countries use our UCC as a model for their own commercial transaction laws. NCCUSL and ALI's decision to agree to disagree on UCITA means that this vital process has failed. There's nothing wrong with that, as deliberative bodies are sometimes unable to come up with a good answer to a perceived need, and it's better in that case to just go back to the drawing board than to try to enact bad law. What's frightening is that NCCUSL has clearly decided to go it alone and abandon a process that has worked in the past. It's not surprising that the 2B folks would feel that way—when speaking with committee members at their February 1999 meeting, I several times heard things like, "We've been working on this so long, it's time to get it finished"—but it's surprising that all of NCCUSL would take this approach. It's even sadder when you consider how many groups oppose the former 2B. The Motion Picture Association of America, the National

Page 115

Association of Broadcasters, the Recording Industry Association of America, the National Cable Television Association, Consumers' Union, the Newspaper Association of America, the Magazine Publishers of America, the American Library Association, the American Association of Law Libraries, and others have written letters to NCCUSL and ALI in opposition to 2B, now UCITA. UCITA Considered Overall Ed Foster found watching the 2B creation process a bit disappointing, saying back in October 1997 that "2B is too industry-oriented. It's going to be very hard to take out all of the industry bias at this point. I can't see anything in it now that I could show to my readers, business customers, and say 'Look, here are reasons why you would want this to pass.' Right now, if you go to court on a software case, it's chaos, you don't know what's going to happen, as the judge can pick from a smorgasbord of precedents and case law. But right now, I'd say you'd be better off than you would be with Article 2B."13 [As the decision to change from building a new part of the UCC to going it alone with UCITA happened very late in the writing of this book, many of the interviewees here referred to 2B rather than UCITA, because the UCITA name hadn't existed at the time.] Todd Paglia said basically the same thing to me: "The UCC 2B draft allows provisions that are actually worse than most software licenses today. UCC 2B in its current state doesn't require a vendor to do anything." Ed Foster went on to add, "It's a shame; I thought that 2B could be a vehicle for software quality. For example, vendors might be more likely to disclose known bugs. This is one of the industry's great sins, I think. You as a customer buy a product and find out that it doesn't work for some reason, some bug, so the product is useless to you. Then you find that this flaw was known, and it happens all the time, even to knowledgeable users because they just can't find out. Bugs aren't generally known [to software buyers, but they're] known inside

Page 116

the company. I've always hoped that Article 2B might help there. A number of software publishers' representatives on the 2B committee have told me that if 2B said that a software publisher cannot be sued over previously disclosed bugs, they'd welcome it. If 2B were to give them protection against suits over bugs if they made bug lists public as soon as they knew about them, having a list of known bugs on your Web site. This would give the customer a fighting chance to know about this stuff. And I think most software publishers would be willing to do it as long as their competitors had to do it also. That's one of things that restrains any software company right now. If you're honest about disclosing your bugs, then your competitors will beat you up for it." Ed then unwittingly predicted ALI's split from the 2B process, saying "there are a lot of people in ALI who have some serious reservations about 2B. There are a lot of issues that 2B is trying to address, and quite frankly they need a Solomon about some of them." While NCCUSL (and, previously, ALI) doesn't pay people for their service in assisting in the drafting of UCITA, most people involved aren't losing money by being involved; the private firms, universities, or government agencies that are their "day jobs" typically allow them to attend meetings on company time. There are, however, a lot more software firms willing to lend their folks to the UCITA process than there are consumer groups willing or able to do the same, so there aren't many consumer advocates at the NCCUSL and ALI meetings. And not many private attorneys with practices to worry about are willing or able to give away their time to work in consumers' interests on UCITA, which is part of the reason that UCITA is, as Ed noted, very industry oriented. One exception is Cem Kaner. In any story, there are heroes and villains. Where UCITA and consumers are concerned, Cem is a hero. Wherever I went in researching this book, Cem's name came up. Cem has been following the UCITA process for the past few years not because it's making him money—it isn't—but because he feels the process has gone sadly awry.

Page 117

"Article 2B blesses the contract of adhesion to a remarkable extent in mass market transactions. So long as vendors comply with a small set of easy-to-meet procedural requirements, every term in the license—no matter how outrageous—is treated as if the customer had actually bargained for and agreed to the term," 14 Kaner said to NCCUSL after sitting at one of the drafting meetings. He went on to say in an article for Software QA Quarterly, "Sometimes I felt completely alone in my advocacy for customers until Todd Paglia and Ed Foster started attending the 2B meetings."15 That's a feeling Todd Paglia understands. "This has gotten out of control, and the software industry has become in control of the process, and if it continues, it'll be law soon." You can hear the frustration in Todd's voice as he recounts: "In these UCC meetings, there are about seventy lawyers, and maybe two consumer reps, twelve drafters, and the rest of the people are from Oracle or Microsoft and it gets to the point where you're arguing about even simple things, then the software publishers, the Business Software Alliance, they say, 'if this goes the way the consumer reps want, me and all my members are just going to walk out and we'll oppose this law.' "Essentially, the software companies [control] the 2B drafting process. Whenever there's an attempt to hold software companies to the same standard as other types of firms, the software firms just threaten to walk out and to oppose the new rule. The drafting committee then just buckles under the pressure." Todd's version is shorter: "2B is essentially broken as laws go; if it were a car and you turned the key to start it, it would explode." Problems With The Proposed UCITA Specifically, what's so bad about the law? Cem Kaner cites the fact that software vendors can now essentially write anything into a contract, pointing to some particularly anticonsumer items that appear in some current software licenses.

Page 118

In an analysis of the then-2B submitted to ALI, Kaner points out that some software licenses actually prohibit you from reviewing their software in a critical way. He quotes McAfee's Viruscan license as saying, "The customer will not publish reviews of the product without prior written consent from McAfee." Astounding. What Hollywood director, book author, or recorded musician wouldn't like to be able to require consent before a newspaper could print a written review? NCCUSL wasn't happy about this, and directed the 2B drafting committee to take into account "public policies beyond software interests." In response, the drafting committee added a clause to 2B saying that any license is invalid if it "violates a fundamental public policy involving free speech, innovation, or competition." Kaner says that the change doesn't change much at all. "Even under the modified 2B, McAfee could still claim that you accepted a contract wherein you agreed not to review the product; they'll argue that you agreed to a nondisclosure clause. Such things exist in contracts, so they wouldn't be immediately laughed out of court. As a result, anyone wanting the right to review Viruscan might have to fight it out in separate courts in all of the fifty states." The resulting uncertainty is sufficient, Cem said, to have a chilling effect on free speech. It would also allow vendors to keep people from reverse-engineering their products, and that's bad news for consumers. "Suppose I build a piece of software that's supposed to work well with some other piece of software, something from a large software company. But try as I might, I can't make it work with the big company's software, and I need to do that before I can ship it. I call the big vendor and they're not much help, so what do I do. Well, if I know how to reverse-engineer a piece of software, then I can take a sneaky peek at his code to see what's wrong. What I usually find out is that the big company's software doesn't actually work the way the big company says that it should. And suppose I write a Windows program that for some reason won't print? If I can't take a peek into the Windows printer drivers, I'll never get my program to print. How does that benefit the consumer?

Page 119

"Further," Cem continues, "reverse engineering can't be that terrible a thing, as it's been recently asserted by a 1998 modification of copyright law called the Digital Millenium Copyright Act." For another example of what would be possible under UCITA, consider this: a market leader in a particular niche market could shut out all competition if reverse engineering is disallowed. Cem explains how it would work in "Legal Issues Related to Software Quality," a paper accompanying a keynote address he gave at the October 1997 meeting of the American Society for Quality in Memphis. "Here's an example that I've discussed with some publishers' lawyers. If I wanted to make a word processing program, I would probably want it to be able to read (import) documents from my competitors' files. For example, Microsoft Word and WordPerfect can read each other's files. Many programs can read competitors' files today, and they are able to do that because their publishers are able to reverse-engineer their competitors' file formats. Under 2B, I would need my competitor's permission to reverse-engineer its file format. I probably won't get that permission, so my program probably won't be able to import much data from competing products. Suppose that you have lots of documents that you've written using your current word processor. I offer to sell you a new word processor that you really like. Unfortunately, my program can't read your old files. Would you buy my program? Probably not. By making interoperability very hard to achieve, Article 2B makes it hard for a new competitor to enter the market." Kaner goes on to ask, "What benefit is there from a law that gives a publisher broad new rights to block the development of competitive services or products?" These provisions haven't been upheld in any court case, and there are questions about whether they could be or not, but Cem points out that if UCITA was adopted by all fifty states in its current form, the courts would be a bit less likely to strike it out. UCITA would have another broad-ranging side effect, according to Todd: many of the basic protections that we take for granted when

Page 120

we buy things could be whisked away when we buy information-related things like software, music, videos—or even books, if the books are on disks rather than paper. ''[The section of the law in UCITA has] become its own little world," he says. "2B covers things that are neither a good nor a service. It covers software, databases, and other information products, as well as just about any product bought through the Internet. "Right now, if you walk into a store and buy a loaf of bread, a car, or a book, you get certain rights, and the seller can't take them away from you. 2B, in contrast, covers the notion of a 'click wrap' product," Todd Paglia explains. "You buy a music CD from some Web site and a little box will pop up saying 'Click OK to agree to terms,' and there'll be a button to review the terms. Almost no one will bother to review the terms, and no matter how goofy the contract is, it'll be valid under 2B. If you'd purchased that music at a music store, however, you'd have all your normal rights. You're penalized if you're buying on the Internet." Jamie Love continues: "And where do we expect much of the sales growth in the next ten years? Internet sales." And what if you did take the time to read the click-wrap sales contract and decided that it was bogus? You certainly wouldn't be given the opportunity to negotiate a different deal. Take it or leave it—sure sounds like a textbook contract of adhesion, doesn't it? "Absolutely," Todd agrees, echoing Cem Kaner's earlier sentiments. "2B essentially says contracts of adhesion are fine, which is a big sea change in the law. For the software industry this'll be incredibly useful. The problem with shrink wrap licenses is that if we're going to consider them to be valid, then we've got to ask: what goes in [those licenses]? 2B allows right now that if you sell a program and if it has flaws in it such that it ruins your hard drive, destroys data, anything like that, then your total remedy is just return of the purchase price or a new copy." In an it-would-be-funny-if-it-weren't-so-sad aside, the UCITA committee decided in 1998 after more than a year of debate how to address the concerns of consumer advocates that people wouldn't read

Page 121

the click-wrap contracts: UCITA would require you to not only click "OK" to answer the question "Do you agree to these terms," it would also require you to click "OK" to another question—''Are you sure?'' The Software Industry Helps Itself To Some Self-Help You're working hard at a deadline, burning the midnight oil. You're just about to save your document, and the word processor freezes—but it's not a bug, it's a feature. A dialog box appears, informing you that your one-year subscription to WordBlaster has elapsed. It then offers to take a credit card so that you can buy another year. And for some reason, this second year's license costs five times as much as the first year's license did. (Call it the "heroin dealer" model of software marketing.) But you've got to get that report out, so you pay. Feels more like ransom than like a transaction, doesn't it? Or imagine this: You're the office manager for a fifty-person law office. You use a particular piece of software to run the office— LawStar, from a firm named MicroBrief. You've added a third person to your billing staff and need to update your license—hey, you're a law firm, gotta keep things legal—so you call MicroBrief. The account person on the other end says, "You're calling us about a third person? Our records show you only bought enough licenses for one person to do billing." You're not quite sure, but you think you can get the records showing that you paid for the second license; can you call the person back?" "Sure," she says. Twenty minutes later, the office system stops dead. You try restarting everyone's system, but LawStar refuses to boot, displaying a message saying that your system is locked until your firm is properly licensed. You see, the MicroBrief person wasn't sure you were being completely honest with her, and she didn't want to have to chase you down, so she sent an e-mail message to the copy of LawStar in your office, telling it to just shut down. To get your system turned back on, you've got to pay more license fees (for some reason they escalate

Page 122

with the number of people), as well as a "transaction charge" that MicroBrief assesses for all that customer service time. Of course, these are just silly, paranoid scenarios, right? Wrong. UCITA allows both the first, called a time bomb, and the second, which goes by the name self-help. "The very idea of this drives the movie industry crazy," Cem Kaner tells me. "Suppose some studio is partway through creating some movie with animation and special effects that require a particular piece of software, and the software vendor pulls these kinds of shenanigans. The end product—the movie—is worth so much more than the software that they'll pay, they'll have to. All that work they've done is now sitting in files on a disk that only that particular piece of software can read." At that point, the moviemakers need that software vendor like they need oxygen. Prior to UCITA, the very idea of a software vendor doing something like this to a client would be unthinkable—or actionable. If UCITA passes in its current form, time bombs and self-help will be normal business practice. "Sauce For The Goose ..." Ironically, the industry likes shrink-wrap licenses when customers must live by them, but not so much when it's the vendors themselves on the receiving end. In 1995, the Software Publishers' Association went to the Federal Trade Commission and complained about software licenses. They said that software licenses (from non-SIIA members, probably) "dictated" terms (to SIIA members). Kenneth Wasch, SIIA's president, testified to the FTC that in many software licenses "the licensor effectively dictates the terms of the required license—essentially on a take-it-orleave-it basis."16 Take-it-or-leave-it. Just like the terms mentioned earlier in this chapter. Provisions like, "This is a license, and the software vendor can revoke it any time they feel you've done something wrong." Provisions like the maximum dollar amount that a software vendor

Page 123

would have to pay in damages—the exact amount could vary from state to state. Now, the notion of limitations of remedies is just fine under current law, but only if you tell the buyer about those limits beforehand. Under UCITA, the software vendor can wait to tell about the limits until after you buy the software. Under UCITA, the software vendor could then just choose to offer its license under the rules of that software-vendor-friendly state, and those provisions would apply throughout the entire country. Take-it-or-leave-it provisions like "We disclaim all warranties," meaning, "This software doesn't do anything and you agree to leave us alone if it's no good." Or controlling where any legal action must occur, so that any lawsuits filed against the company must be filed in Guam, where the case would also be tried—just the airfare to bring oneself and one's witnesses would be enough to keep most people from filing lawsuits against the makers of rotten software. Or for software support: suppose you find a bug and call the vendor, only to find that you've got to pay for product support just to report their bug—and, as you're charged by the minute, the call actually costs more than the software! Or imagine this: you've been using some piece of software for a year now, and you're finally used to it. You've got a bunch of files created with that package, and only that package can read these files. You go to start it up, and it tells you that your one-year license has expired. You call the vendor and are told that the one-year provision was indeed in the click-wrap license—you did click "I Agree," didn't you? No, they explain, the fact that the software would only run for one year actually wasn't mentioned on the box or in their ads, but, hey, that's not required by law. You know, that UCITA law ... Conspicuousness Redefined Which brings us to the notion of conspicuousness. Suppose we decide that we don't care that shrink-wrap or clickwrap software licenses are

Page 124

contracts of adhesion; okay, they're take-it-or-leave-it contracts. Can I at least find out how bad they are before I buy the product? Not always. Licenses that you cannot see until after you've purchased them are often viewed by courts as requests by vendors to modify the sales contract. (Remember Step-Saver v. Wyse.) As Cem Kaner points out in the notes to his "The Law of Software Quality" seminar, we're so used to what's in software licenses that we tend to forget how truly rare this idea of changing the rules after you've bought a product or service is. For example, try selling your car to someone and putting a note inside the car that says that you, the seller, get to keep the tires unless the buyer wants to purchase them for an extra $10,000. Then wrap tape around the car doors, and be sure to write on the tape "breaking of this tape constitutes acceptance of the enclosed license." But think: isn't there something familiar about all this "it's not my fault" licensing? Haven't we all seen a transaction like this before? Picture this: you pick up a piece of shrink-wrap software in the store. You can't read the license, as it's shrink-wrapped in the box, but you have some expectation from the fact that it says "Word Processor" on the outside that it processes words, and that it is reasonably defect free. The "Designed for Windows" logo means that at least someone has been able to make it work. But you take it home and open up the box, only to find some silly ''we don't promise this does anything" license. Here's an excerpt from an actual one, Lotus's Ami Pro: "Lotus makes no warranty, representation, promise, or guarantee, either express or implied, statutory or otherwise, with respect to the Software, user documentation, or related technical support, including their quality, performance, merchantability, or fitness for a particular purpose.''17 In other words, if you happen to find Ami useful for anything, they'll be as surprised as you. Still sound familiar, but can't put your finger on it? Consider this: it sounds (to me, at least) as if buying software is like buying a used car. Used car salespeople openly say that you take a risk when buying

Page 125

a used car. And by law, if they're not willing to stand behind the used car, they must conspicuously place a sign on the car that says that it's being sold as is. Perhaps it's no coincidence that the Better Business Bureau now gets more complaints about the computer business than it does about used car dealers! As one advocate has said, "If we're going to be used car salespeople, let's just admit it." Under current federal law, the terms of contracts concerning things costing more than $15 have to be conspicuous. The terms of a contract have to be easy to review before buying. They can be on the product's box, or on a sign displayed near the product, or available for customer review upon request. But under UCITA, the terms of a contract can be conspicuous even if the customer cannot see the contract before the sale. Todd Paglia explains, "[Under UCITA], these items can be 'conspicuous' when installed, they need not be on the box. The software vendors have fought us tooth and nail [about putting conspicuous notice on software packages] and they've actually said that there's no room on the box. In other words, they've got a bad balance between their consumer information and their marketing information—and we've gotten nowhere on that." The reasoning offered by those in favor of watering down conspicuousness requirements is that as long as the consumer gets to see the terms eventually, she can always decide to abort the install and take the software back to the store for a refund. The UCITA drafters seem to think that this is equivalent to allowing a consumer to see the license before she buys the software, but of course it's not. People traditionally don't bother returning defective stuff, as argued earlier in this chapter. Cem Kaner observes, "If we want to write a statute that reflects commercial reality (which used to be the UCC goal) then we should be taking this fact into account, not pretending that it isn't there or isn't relevant." Additionally, if vendors had to inform us of every abnormal anticonsumer aspect of their software licenses right

Page 126

there on the box for everyone to see, they'd be less likely to put them in the license in the first place. And how hard would it be to make the license easy to read before sale? Not hard at all. It's just a short text file; vendors could put it on their Web sites. But, laughably, software industry representatives claimed that this would place too much of a burden on software firms, according to Ed Foster.18 (Finding this hard to believe, I asked a few vendors myself, at the 2B drafting meeting. I got the same answer. When pinned to the wall about how simple it would be, they all retreated to, "No one else has to do this, why should we?") So let me get this straight: they're going to sell you software over the Web. The way the click-wrap license works is that you first give the Web site a credit card to buy the software. Then you get the chance to read the license, agree to it, and only then can you download the software. So they're able to put the license on their Web server so that you can read it after you've bought the software, but it would be too much trouble to let you read it before you buy the software? That's obviously bogus; what's going on here? "This is what 'conspicuous' is all about," explains Cem. "Why do you think warranties on cars are so good—5 years or 50,000 miles, that kind of thing? Because if Chrysler does it, then GM had better do it, because under law both Chrysler and GM must make the terms of their warranties publicly available, even to people who don't buy their cars. It means that the public can't compare licenses. Consultants can't. The press can't." Jamie Love offered a few thoughts about what should be conspicuous in software sales. "What if there were a list of, say, six things about the license that should be public; it's informative and helps. It would be nice to know whether the vendor scanned the software for viruses. Or spell out the terms of the warranty. Maybe whether or not you can resell the software. How long will they stand by the product? How many bugs does the vendor know about right now?" But nothing's being mandated.

Page 127

A Process Out Of Control Yikes! This is sounding kind of scary. Is the UCC drafting process normally as uncaring about consumers? "No," Todd says. "They've done some very important stuff in the past. But the BSA and SIIA just push the drafting committee around. We'll get through a discussion of quality and the software industry guys just overwhelm us every time; ten of them speak for every one of us. The drafting committee is, at this point, up against the wall. They feel like Big Software is after them and if they change the draft in any way the software companies don't like, they'll get screwed." Todd goes on to cite a chilling example he witnessed at an American Law Institute meeting. "Originally, ALI was going to approve 2B at one meeting, but the ALI vote was delayed until the next meeting, the 1998 meeting. But here's an amazing story. There was a motion made on the floor to deal with copyright issues, and it was approved by a majority of voting ALI members. It said that 2B should include a clause saying that software licenses cannot include language contravening copyright laws." So this motion just said that no part of 2B should try to supersede copyright law. Copyright law is federal law and that generally supersedes state laws anyway, so it's a bit of a moot point. But listen to the rest: "So the motion was presented, it was all of one sentence, and it was approved. This survived for about an hour. I know because I was at the meeting! Next week there's another meeting, this time in Cincinnati, and people start talking about the need for a transcript of last week's proceedings. They were saying as the motion that passed was only orally offered, it didn't get into the record and so was moot. We argued about this for two hours in Cincinnati, and the opposition argued, 'Well, people didn't know what they were voting on,' and I replied, 'This was one sentence.' In effect, the industry got this killed." The idea is that if the software industry isn't happy with the law,

Page 128

they can kill it. So what if Microsoft opposes UCITA? Would the public care? Would the state legislators? "The committee buckles because the software people buffalo them by talking about how they can't possibly understand the underlying technologies. The drafting committee is told that 'Software is infinitely complex, that you can't have any kind of quality without killing the industry'—it's something that flies. Software guys come and say to the committee, 'Hey, software is just this thing that I can't even explain to you—it's just billions of lines of code and it's unbelievably complex.' So the drafters are afraid of looking stupid, of requiring impossible things of the industry." Shrink-Wrapped Viruses, Courtesy Of UCITA "Here's an example," Todd told me in mid-1997. "Consider viruses—what responsibility does a software vendor have to at least scan for viruses before releasing a product? The draft of UCC 2B says that for Internet transactions there is no requirement for viruses to be removed. All you must say in the license is, 'No attempt was made to remove viruses.' And, of course, you can't see the license until you're installing the software." Now that's frightening. That little click-wrap dialog box that will appear offering to show you the license and including the button labeled "I agree to the terms" is itself a program—and any program can be virus infected! The idea is this: when you buy a program, the program is itself wrapped inside a program called an install or setup program. Install/setup programs can have viruses—yet 2B is saying that vendors have no obligation to try to keep viruses out of those install/setup programs unless they're supplied on floppy or CD-ROM! That sounds pretty sad, but it gets a bit worse. In late 1998 Todd ruefully explained to me that the latest draft of 2B removes the physical medium/Internet distribution dichotomy by not requiring vendors to scan for viruses when distributing physical media. Again,

Page 129

all they need to do is note in the license agreement that they made no effort to make software virus free. How could the software vendor representatives possibly get such an anticonsumer rule into UCITA? Todd explains. "In the meetings we had about an hour and half debate in a room full of lawyers, and I don't know a hell of a lot about viruses, but there were lawyers from the SIIA saying 'viruses cannot be removed,' and Intel and the software companies went on at great length to explain that there's no way to remove viruses. That's crazy, of course there are antivirus programs, you can digitally sign files—but the lawyers on the drafting committee are just saying to themselves, 'Wow, well, here's Intel and the software companies saying it's impossible, so it must be. Clearly the Internet is just the Wild, Wild West and so there's no way to keep products from the Net clean—it's just the nature of the Internet.' The drafting committee has no knowledge of the digital signing technology, so they must listen to the software companies." [Digital signing is a technology whereby someone can put a file on a Web site and include enough information so that when you download the file, your Web browser can verify that it came from the vendor you thought it came from, and that it wasn't modified along the way.] "Because They Can" Why is the industry playing such hardball? Why do companies want software licenses to be so anticonsumer? "Because they can," Todd says. He feels that industry was more reasonable in its demands up until Judge Easterbrook found on appeal for ProCD, but now that the companies have ProCD, they've got a pretty good legal precedent upholding the terms of software licenses, contracts that the consumer doesn't get to see until after purchase time. Why muddy the waters with a new version of the UCC unless it's entirely in their favor?

Page 130

"If you talk to SIIA or BSA ... get them to say the word consumer. When they say it, it almost comes out like a four-letter word. It's unbelievable how much animosity they have towards consumers in general," Todd told me. "The amount of contempt for users by companies is incredible. I was in Cincinnati for that 2B meeting and I was sitting next to a gentleman from one of the big companies, and someone was posing a hypothetical situation, saying, 'Well, suppose this happens and some stupid consumer does this,' and the software guy next to me says under his breath, 'What other kind of consumer is there?' It's the same kind of thing you see in small tourist towns, where they hate the tourists, even though the money from those tourists keeps the town's economy going. The software companies really have to ask themselves, 'Who's supporting us?' "Another problem with getting anything pro-consumer into the bill is the reporter, Ray Nimmer," Todd says. "I would guess that if Ray Nimmer had to include the types of provisions that we'd like to see, like seeing the license before buying the product, things that give consumers the information that they need to make an informed decision, then he would not want to be part of the process and might resign." It's no wonder Nimmer's perspective is provendor, Todd says: he quite literally works for the vendors. "He is also counsel for a firm that represents large software companies. He's got an agenda, and he's going to push it." Other observers of the process have said very similar things to me on the condition that I not name them—"Ray doesn't want anything to do with a pro-consumer bill," one said. If that's true, it's sad that the author of such a well-worded argument against shrink-wrap-softwareas-licensed-good quoted earlier in this chapter would turn out to be the point man on a piece of law that would make all software sales licenses. And in the end, Todd argues, a rabidly anticonsumer, pro-vendor UCITA could hurt the software companies the most. "I think it could end up leading to regulation in the end when the backlash eventually occurs. Software is now in the top ten complained about industries

Page 131

according to the Better Business Bureau, and that's before this law is even enacted. What'll it be like after? What if it's number one on the Better Business Bureau's list for several years running? People just want to get software up and running to get some work done, and there's lots of people having trouble. When a significant number of your customers are having trouble making your product work, at some point it's not their problem, it's yours. Beyond that, there's the very real issue of, 'Are you treating consumers fairly?' There's always a balance in the sense that an industry that derives large benefits from a market has some responsibility. Is it fair to say that all of the responsibilities should lie with the consumer? This law says that all of the damage that can occur from bad software should be on the consumer's shoulders, and the industry gets all the benefits. I think there are a lot of people frustrated with software, but they don't have any idea how many other people are frustrated with software.... For a software vendor, it's like this [if UCITA passes in its current state]: I'm putting out a questionable product, and I get to charge you for customer support, and I have no liabilities to worry about. I'm making money no matter how you look at it." UCITA'S Current Status How far along is UCITA right now? At ALI's annual meeting in May 1998, the membership passed a resolution saying that "The current draft... has not reached an acceptable balance... and should be returned to the Drafting Committee." That was no doubt a precipitating event in converting UCC 2B to UCITA. So the legislation is still a long way from passage, it seems. A startling number of industry groups have come out against it, including the ones mentioned earlier in this chapter. Many who've looked at it feel that UCITA is, as the Motion Picture Association of America said in its letter to ALI's directors, "fatally flawed." At this writing, it appears that the NCCUSL general membership

Page 132

will consider UCITA for general approval at its annual meeting in Denver, taking place in July 1999. If UCITA is approved by NCCUSL, all fifty state legislatures will then consider it. UCITA was originally designed to allow the UCC to evolve to encompass the emerging world of high technology. In a memo, Ray Nimmer says, "[T]he modern U.S. economy no longer solely depends on sales of goods. It encompasses intangible property transactions. Information license contracts entail far different commercial and practical considerations than sales of goods model." 19 In other words, this stuff is important and we've got to do something about it. But UCITA has grown beyond that, according to Kaner. UCITA can actually apply to books, he argues. So don't be surprised if the next book you buy has a license reading something like this: "You are granted a LICENSE to use this book. You have NOT purchased this book. By opening the book, you agree to the terms of this license. Only one person may read this book. Once it has been read by that person, that person may choose to reread it as many times as he or she desires, up to the expiration date of this license. Under NO circumstances may this book be lent to others, resold, or given away to another individual or library. This license expires 180 days after purchase of this license. Once the license has expired, you must destroy this book, or you may choose to return this to the publisher so that it may conserve Earth's precious resources and recycle the book's media." (Recycle it back onto the bookshelves so someone else can buy it, that is.) I posed one more question to Stewart Crumpler of the FDA, thinking about his comment about there not being any advantage to turning out good code in the marketplace. "Bad code may sell in the short run, but what about in the long run?" I asked. "Adding features is a good short-term strategy. But wouldn't a software firm look beyond the short term and see that there's a smaller and smaller value to that marginal feature, and greater value to quality?"

Page 133

"Who in this country thinks about the long term?" Stewart responded, with a shake of his head. Of course, folks in other countries look to the longer term, I replied. "Exactly, that's exactly the issue," he said. Foreign competition in the software business? That's the topic for the next chapter.

Page 135

Chapter 5 Bugs And The Country: Software Economics At 2:26 A.M. on 3 June 1980, Colonel William Odom of the Strategic Air Command alerted National Security Advisor Zbigniew Brzezinski that the U.S. nuclear warning system had detected an imminent 220-missile nuclear attack on the U.S. Shortly thereafter, the automated system revised its projection from 220 missiles to an all-out attack of 2200 missiles. Just before Brzezinski was about to wake up President Carter to authorize a counterattack, he was told that the ''attack'' was an illusion caused by "a computer error in the system." —Stansfield Turner, CIA director under President Carter, in his book Caging the Nuclear Genie—An American Challenge for Global Security (Westview Press, Boulder, Colorado, 1997)

Page 136 The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in. We're computer professionals. We cause accidents. —Nathaniel Borenstein, inventor of MIME (the standard used for sending attachments over Internet e-mail) and chief scientist, First Virtual Payment System, in Programming As If People Mattered: Friendly Programs, Software Engineering, and Other Noble Delusions (Princeton University Press, Princeton, New Jersey, 1991)

Page 137

We've seen so far that bugs are costly, that software developers could easily produce software with many less defects, and that unless something's done about it, selling buggy software could become stoutly defended by the Uniform Commercial Code. If by some odd chance you are both still not sure why I'm making such a fuss about bugs and you're still reading at this point, consider this: If something isn't done about bugs, they could kill most of the economic growth we've made in this country in the past fifteen years. Is software that important to economic growth? Folks in the software industry think so, not surprisingly. Robert Holleyman of the BSA (which not only pursues software pirates but also collects statistics on the software industry) cites some statistics from a study his organization commissioned, saying, "We have been over the past decade the fastest-growing major industry in the United States. Clearly, it's an engine that's driving the economy. The software industry in 1996 in the U.S. was a $102.8 billion market for products and services. It paid more than $15 billion in taxes. It creates 3 percent of all U.S. employment. It's faster growing than other sectors. And look at the potential for Internet commerce. Not only has growth been substantial, but the potential for more rapid growth is there. I often say that it is the engine that is driving the U.S. economy." 1 In 1996, the software business employed 619,400 people directly, and generated $103 billion in sales. 2 That initially doesn't seem like much when compared to the economy as a whole, where about 122 million people work and the gross national product was $6387.7 billion. What difference does software make? Well, consider that $100 billion and a half million jobs ain't bad for an industry that essentially

Page 138

didn't exist in 1980; I don't think the pet rock industry ever got that far, and it looked like a real comer in the late '70s.3 U.S. Software Dominates The World Market Now consider the following numbers. Trade surpluses/deficits for selected industries, 1996 4 Industry/good type

Exports, $millions

Imports, $millions

Surplus/(deficit)

Software

24,000

4,000

20,000

Agriculture

25,773

13,846

11,927

Aerospace

10,990

2,872

8,118

Chemicals

25,804

18,995

6,809

Vehicles

21,069

42,981

(21,912)

Manufactured goods

200,240

264,779

(64,539)

As the data are from different sources—most of the numbers are from the U.S. Bureau of the Census, but the bureau doesn't keep numbers on the specifics of software, so the software numbers come from the market research firm International Data Corporation—no doubt there's a bit of comparing apples with oranges but even if the numbers are a bit off, they're significant. In 1996, we spent $959,873 million on other countries' products, and they spent $848,833 million on our products, creating a trade deficit of $111,040 million. In other words, the trade deficit is only five times larger than the surplus created by one small industry! If software continues to grow at the rate it has in the past decade or so, it could well close the trade gap. 5 In 1994 (the last year data was gathered), 75 percent of the shrink-wrap software purchased in the world was made in the United States.6 The Economist reported the 1995 sales of the twenty largest software companies; you can see the numbers in the table following. (The Economist chose to define a software company as a firm for which more than 50 percent of revenues were from software sales.)

Page 139 Twenty largest software firms,

19957

Company

1995 revenue, $millions

Microsoft

7,419

Oracle

3,777

Computer Associates International

3,196

Novell

1,986

SAP AG

1,887

Sybase

957

Adobe Systems

762

Informix

709

American Management Systems

632

Sterling Software

610

Compuware

580

SAS Institute

562

Software AG

552

Cadence Design Systems

548

Autodesk

544

Sunguard Data Systems

533

HBO & Co.

496

Intuit

490

Parametric Technology

441

All of those firms are American firms save for Software AG and SAP AG, which are German. (You may remember the quote from Wayne Rash in Chapter 1 about how a package named R3 is quickly gaining popularity because of its stable nature: SAP is the firm that makes R3.) Anyway, the point of the table is that at the moment the U.S. owns the software market, and the software market is helping close the trade gap considerably. This is, however, still pretty ho-hum if you're not clear about why you (or anyone else) should be concerned with a trade deficit. Understanding Trade Deficits The trade deficit is kind of like the federal government's budget deficit: really big, vaguely scary, and something you really only hear

Page 140

about now and then—so here's the world's shortest course on the trade deficit. Please understand, however, that foreign trade is a fairly complex process, so this will be an extreme simplification. The federal budget deficit seems easy to understand: it's just the amount of money that the government spends minus the amount of taxes it receives. Just as you can't perpetually write checks for more money than you deposit in your checking account, so also must the government eventually stop deficit spending. Budget deficits are fairly easy to calculate, as most of the government's bills are paid in dollars and the government receives taxes in dollars. While the idea that both sides in a transaction use the same money seems kind of obvious, it doesn't work that way in international trade. Consider our foreign trade with the United Kingdom. The U.K.'s currency is the pound sterling; ours is the dollar. If folks in the U.K. want to buy a whole bunch of copies of Navigator from Netscape, Netscape will ask them to pay in dollars. British citizens don't have dollars, but that's no trouble—that's what banks are for. The U.S. banking system has a relationship with the U.K. banking system; U.K. banks will sell U.S. banks pounds sterling in return for dollars, and U.S. banks will sell dollars for pounds sterling. But how many dollars does a pound cost? Since 1973, it's ranged from as low as $1.10 all the way up to $2.60. For ease of calculation, let's say the exchange rate is $2 to £1. Suppose, then, that U.K. residents buy $500 million worth of Navigator; they indirectly end up having to spend £250 million to buy the $500 million needed to purchase Netscape. The British now have a whole bunch of copies of Netscape Navigator, and U.S. banks now have £250 million. Meanwhile, suppose a new Star Trek: The Next Generation movie appears, creating a nearly insatiable demand in the U.S. for Captain Jean-Luc Picard's favorite beverage, Earl Grey tea—$900 million worth of demand, in fact. American consumers demand $900 million worth of tea. The British folks selling Earl Grey don't want dollars, they want pounds, so British banks assist by buying dollars in return

Page 141

for pounds so that the transaction can happen. The result: Americans have Earl Grey, and the British banks have $900 million. The Americans are happy, and so are the British, at least for the moment. The U.K. has sold a lot of tea and we've sold a lot of browsers. U.S. banks have £250 million (about $500 million), and U.K. banks have $900 million (about £450 million), so at the end of the year they get together and reexchange the money. At an exchange rate of $2 to the pound, the British banks end up giving $500 million to the American banks and get back the £250 million. Now the American banks don't have any sterling to worry about, but the Brits are stuck with $400 million. Now suppose this goes on for a few years; again, we're happy because we're selling browsers and they're happy they're selling tea, but now the U.K. has this big (and ever growing) pile of dollars. Seems like we're getting the better end of the deal, doesn't it? We send them pieces of paper and they send us actual goods. Effects Of Long-Term Trade Deficits As with all seemingly good things, however, this doesn't go on forever. Instead of saying, "The British have an ever growing pile of dollars," say instead, "The British have an ever growing stockpile of power to own American goods, services, and property." A dollar sent overseas can easily become the means by which people from other countries come to own everything in the U.S.—including land, which means that they may be our landlords, or businesses, which means they'll be our bosses. That makes most Americans uncomfortable, as when in the '80s Japan purchased places like movie studios. That's also how the British bought the Holiday Inn chain of hotels. Or there's another possible outcome. Eventually the U.K. has so many dollars that they decide to just stop taking dollars at the current rate of $2 to £1. They may just say, "Look, if you want our valuable pounds sterling, we want more dollars." The exchange rate may then

Page 142

go to, say $3 to a pound. To a British person, Earl Grey seems no more expensive, as its price in sterling has not changed, but to an American paying dollars, Earl Grey now seems to be 50 percent more expensive. Then Earl Grey becomes more expensive and people decide that they're tired of asking for "Earl Grey—hot" and turn instead to some other beverage. Hopefully enough people switch away from Earl Grey that the British find themselves with a smaller pile of dollars at the end of the year. At the same time, a U.K. resident can now more easily afford Netscape Navigator, as it costs fewer pounds to get enough dollars to buy Navigator. This apparent decrease in the price of Navigator impels more people in the U.K. to buy it, with the effect that more and more of those excess dollars come back to the U.S. Well, now, that sounds okay, doesn't it? No, there's a problem there, too. First of all, the makers of Earl Grey are seeing drastically reduced foreign sales, so they're likely to complain to the British government to do something about this "trade crisis." Or suppose for some reason American buyers didn't stop buying Earl Grey, perhaps because there wasn't much in the way of reasonable hot caffeinated morning beverages. Then the net effect would be that nearly the same amount of Earl Grey was being sold as the previous year, but it cost more dollars to buy. (Substitute OPEC oil for Earl Grey and it'll seem more plausible.) Net effect: we're sending even more dollars to Britain. Now that Earl Grey has gotten more expensive, people find themselves unable to afford it, so they demand higher wages, which forces businesses to charge more for their services, which leads to inflation. And we definitely don't like inflation, that's for sure. The bottom line is this: trade deficits either lead to a greater and greater share of the country being owned by foreigners, or they lead to inflationary pressures, or they lead to both. Worse, if deficits continue for very long periods of time, a country's currency becomes completely worthless, and other nations will not trade with that country. At that point, the habitually deficit country must go to an

Page 143

organization called the International Monetary Fund (IMF) and request assistance; many Third World countries maintain international trade only with IMF assistance. But that IMF help comes at a price—the IMF commissioners don't want to support a country forever, so their help is likely to come with strings attached, like "We'll help you if you balance your government deficit and cut everyone's salaries by 40 percent." Imagine the day that Americans hear that a commission of Germans, Japanese, and Saudi Arabians gets to dictate the U.S. budget and pressure U.S. companies to cut salaries; such a thing could happen if our trade deficit isn't put in order. Countries that habitually run a trade surplus are called creditor nations; those running deficits are called debtor nations. We were a creditor nation for many years, with trade surpluses driven by agriculture, aerospace, consumer electronics, and automobiles. In the early '80s, that changed, and now we're a debtor nation—and no country can stay a debtor forever and remain viable. How To Lose A Market: Automobiles As A Case Study In 1965, the industries that generated the largest surplus ($7.2 billion) were collectively called by the government statisticians of the time machinery and transportation equipment. This category included both automobiles and aerospace, two of our internationally strongest industries; in 1965, automobiles accounted for $1.2 billion of that $7.2 billion. By 1996, when software was generating a $20 billion surplus, autos created a $21 billion deficit. Once, automobile sales fueled our surpluses; now, they anchor our deficits. How did that happen? Again, it's a complex issue, but here's one way to look at it. In the early part of the century, there were significant technological differences between different auto manufacturers. These technological differences mattered in the car buyers' minds: being the first automaker to produce a car that could sustain a speed

Page 144

of 35 miles per hour was a significant technological feat, and it would get people into the showroom with their checkbooks in their hands. In general, running an early twentieth-century car involved a lot of knowledge on the part of the user. For example, tires didn't last much longer than a few hundred miles, so everyone was adept at changing flats. You may know that about once or twice a year a car must be timed, a process that ensures that a spark plug's ignition coordinates properly with the position of the piston in its cylinder. On a Model T, the control for that timing, called the spark advance, was located on the steering column—the user of a Model T had to time the car every time he wanted to use it. A third example: another part of the complex system of control within an automobile regulates the mixture of gasoline and oxygen. That's done with a control called a choke. Once, a car's driver had to modify this fuel-air mixture with a manually controlled choke, but now it's handled with an automatic mechanism, and as a result very few drivers on the road today have any idea what a choke is, or would have a clue how to work it. And, in probably no more than twenty years, it's likely that you'll be unable to find a new car with a manual transmission; all cars will have automatic transmissions. Like any industry, the American automakers wanted not only to sell you one car, they wanted you to have a reason to come back and buy another car in a year or two. They needed a reason to get you into the showroom to upgrade. Of course the car would wear out eventually because cars have so many moving parts, but that would take too many years. Detroit wanted people buying more cars, but how? For a long time, technological advances created the consumer desire to upgrade. Every few years, a new "gotta have it" feature would appear in cars. Newer cars could accomplish things that older cars couldn't, so people would upgrade because of exciting innovations. But at some point—about the mid-'50s—automakers ran out of bright ideas. The differences between car models began to blur. There may have been a day when buying, say, a Studebaker over a Ford made some technological sense, but by 1955 that wasn't true any more.

Page 145

Cars really haven't changed all that much since the mid-'50s; basically, building a reliable, affordable car is a solved problem. (Don't believe it? Then ask: is a 1957 automobile compatible with a 1999 highway?) To continue to create marketing demand, some automakers tried to create new technologies, like cars that could double as boats, but most of those projects were technological dead ends, expensive models appealing to a too-small marketplace. Successful automakers, however, took another tack: glitz. You may recall or have heard of the fascination with fins on cars in the late '50s and early '60s. Slowly the marketing focus moved away from ''our technology is better than theirs,'' a technology-driven approach, to a marketing-driven approach, and that's basically how cars are sold to this day. Car ads sometimes make vague noises about better engineering, but the main message of automobile ads runs something like, "Buy our car and you'll have more freedom, you'll seem younger, you'll be more attractive to members of the opposite sex, you'll be happier." (I mean, just what the heck is Fahrvernügen anyway?) To accomplish product differentiation, automakers came up with less important things, like power windows or more chrome, or those goofy fins. Or they tried to take something that once excited the buying public and extend it further, even if it was in a practical sense no longer that useful. Returning to a previous example, being the first automaker to produce a car that could sustain a speed of 35 miles per hour was a significant technological feat and a good solid reason at the time to upgrade one's vehicle; but having an 8-cylinder engine that could easily attain 160 miles per hour is of no practical value to most buyers. Nevertheless, it seemed like more of a good thing, so more power and more features ruled the day: Detroit started pushing feature-laden gas guzzlers on the buying public. Of course, you know what happened next. The Japanese cars that appeared on the market in the late '60s were pretty Spartan little vehicles, largely bereft of features, not terribly powerful, not much of a threat—but they were reliable and economical. Today, Japan has a 22

Page 146

percent share of the U.S. auto market. At some point, technological advance slows down, so features get less important. At that point, all that's left as a selling point is reliability. Relearning The Automobile Lessons The automobile-software market analogy has occurred to many people. One of them is Mitchell Kertzman, the former CEO of Sybase, one of the largest software companies in the world. (He is now president and CEO of Network Computer, Inc.) In a recent interview, Kertzman had this to say: "I worry that our industry, the computer and software industry, technology industries, have fallen into a trap that the American automobile manufacturers were in perhaps in the '50s and '60s. This was a time when American automobile manufacturers dominated the world market and sold cars that were obsolete every three years. They weren't built to last longer than three years, and the design movements—you know, raised tail fins, lower tail fins, all of the radical design changes—were meant to have people throw out their old car and trade it in for a new car. Every three years. The industry was based on the assumption that that was what the customer wanted. A new car every three years. And it took the Japanese in the '70s, along with the oil crisis, to demonstrate that what customers really wanted was cars that lasted longer than that. They wanted quality. They wanted reliability. They wanted things that American manufacturers didn't know people wanted because they weren't asking for it. I get concerned that our industry has been built around the obsolescence of our existing technology every three, four, five years, however long it is, with the idea that people should throw out their existing technology, whether that's the PC in the home or the very large computer in the corporation, in favor of some brand new product and architecture that has, we claim, great benefits. And that in fact it may be true that that's not what customers really want." 8

Page 147

I called Mr. Kertzman up (while he was still with Sybase) and asked him to expand on these thoughts. "In the '50s and the '60s, the American automobile industry was built on the notion that what customers really wanted was a new car every three years. The computing industry does the same thing, radically changing technology every few years. The whole industry is based on the notion that our customers don't want to finish installing the software we already sold them, they want to throw it all out and buy something new, preferably something that feels like a magic bullet, every few years. A few years ago it was client-server computing, now it's network computers. The industry is based on the notion that people want to get Windows 3.1 and then throw it out and get Windows 95 and then throw it out and get Windows 98 et cetera et cetera." I was going to ask him at that point about whether quality will ever become a selling factor in software, but before I could, he took the words right out of my mouth. "I ask the question: how will our industry respond if we ever get a change in behavior in customers and it becomes clear that what they really want is just software that works. And works for a long time. I gave a pitch along those lines at a conference recently to a room full of users of software and it got the biggest round of applause. I think customers feel that they've got to keep up with technology, but that they don't like it. So this isn't purely an issue of quality, but also continuity, that you don't have to throw out stuff in order to use something new." Reliability sells. Quality can be a feature. Could that be the Achilles' heel of the industry? Some of the other experts I talked to thought so, some disagreed. I asked software development guru Ed Yourdon, "Will a foreign power steal the software market from us?" In answering, he mentioned some of the big topics in the software market today. "It could well be, although not necessarily. I thought so five or six years ago. I was very concerned at that point that countries like India

Page 148

could do it. They had the combination of good education, cheap labor, and an emphasis on quality. What the Indians don't have is an appreciation of marketing and distribution. Microsoft is probably just as much of a success because of Bill [Gates]'s market savvy as for any software savvy. Over in India, about three years ago, I ran into one software product company, and I said to them, 'Why don't you or some other company come up with your own version of Microsoft Word—surely you can do it—so what's the secret about word processing software?' He said to me, 'Sure, we've done that, but we can't compete with Borland or Microsoft—they can wage price wars and kill us, as it's kind of hard to compete with a word processor selling for $1.98, and they could take the price that low. Besides, our packaging looks terrible, it looks sloppy, and the manuals are terrible.' Packaging and marketing of software is something that we're very good at in this country. "In any case, I don't think it has to be a foreign threat. In the last couple of years, Netscape and Java have presented some challenges to the established big software companies. The concern that the market is starting to have about this total cost of ownership—say I'm a CIO at a company with 25,000 employees, and every time Microsoft comes out with a new upgrade of Office or Windows, the hassle that it causes for varying versions around the firm is just incredibly awful, and if I can replace that with the Java paradigm of having all the applets downloaded dynamically at just the moment that it's needed, then my administrative costs will go down. I'm oversimplifying, of course, but it's a big issue. Bill [Gates] only started this Zero Administration Windows thing in response to what other people were doing. He would never have come up with this on his own had he not seen some very serious competition arising from Netscape, Sun, and others. If a software company anywhere else comes up with a great word processor that runs quickly, never crashes, is competitively priced and offers good service, that might force Microsoft to change." Cem Kaner isn't worried that other countries will move into the

Page 149

software market; as he sees it, they already have. "They already are. I know of several pieces of software that I'm positive you think are American, but the code is written in the Bahamas or Japan. The user interface code is written in the U.S., but the rest is done overseas. A lot of game software is done in Japan except, again, for the user interface." And recall from Chapter 3 the location of the only Motorola software shop that qualifies for CMM level 5 certification—Bangalore, India. John Horch, the software quality expert we met in Chapter 1, has done a fair amount of work in Bangalore. "They turn out some very good stuff, and there are some incredibly sharp programmers there. The quality of their educational system is a contributing factor as well. But will they compete with us? Hard to say. My feeling is that they don't know how to get into the marketing channels here. And, truthfully, their biggest enemy is their own government—the Indians have raised bureaucracy to a high art. Getting a product approved for export is very difficult." In other words, once the Indian software firms decide to take over the U.S. software market, all they need to do is to clean up their manuals a bit to make them a bit more American-culture-friendly, hire a U.S.-savvy marketing firm, and persuade their government to get out of their way? Hmmm ... those are all eminently fixable problems. I can't say that I'm sleeping better at night knowing that the U.S. software market is being defended by the quality of Microsoft and Lotus user manuals! What do the software companies themselves think about the prospects of foreign competition? Sadly, most refused to be interviewed. But I had the chance to speak with a friend from Microsoft, Tom Campbell. Tom's the program manager for Visual Basic for Applications, a relatively easy-to-use programming language that is quickly becoming the glue for all of Microsoft's applications. Tom's not speaking for Mightysoft, of course, but he had an interesting point of view.

Page 150

"Software is a pop culture item," he said, "like movies and music, rather than a technological item. In movies and music, we're the kings there, and there's no sign that that's going to change. There are some countries with an incredible thriving movie industry, but they're just invisible here. Take India, who you mentioned about software. They also have a very large movie industry, but those films just don't make a dent over here—or anywhere outside India, for that matter." Internet Security And The Software Market And there's one more voice to add here—Robert Holleyman of the BSA. While he might not be the software consumer's best friend, he is also charged by his customers, American software firms—the largest of which is Microsoft—with protecting their ability to create and hold market share overseas. Holleyman is worried about foreign competition and preserving American competitiveness, but for a different reason. "I do think there's something to worry about, and I'll give you a classic example of it. The world is shifting to a network-based economy and there are substantial upgrades happening all around the world as we move from the world of freestanding computers to a world of networked computers." It's at times like this, he feels, that firms reevaluate what software they're using, and those are the times when new vendors can get a foothold in a new market if the old vendors can't deliver what the customers need. "U.S. software companies right now are clearly blocked from any substantial entry in the global market that includes strong security." I realized he was talking about encryption standards. As the Internet becomes more widespread, people will do more and more shopping on it. But there's a lot of concern about security on the Net, some of which is justified. Say you go to L.L. Bean's Web site and

Page 151

decide to buy a shirt. Bean's computer takes your order, asking for your size and color preference, address, and of course credit card number. That information travels across the Internet to L.L. Bean, and your order is confirmed. A few days later, the shirt arrives. A week or two later, the credit card bill arrives, with thousands of dollars in charges for things that you never bought! That's the horror story, anyway. The fear that many people have about sending credit card information over the Internet is that someone will eavesdrop on the electronic conversation and learn a purchaser's credit card number. In actual fact, sending credit card information over the Internet is probably more secure than giving your credit card to a waiter (who may actually earn less than minimum wage in many restaurants) who disappears into the kitchen with the card for ten or fifteen minutes. Nevertheless, it's still a good idea to secure Internet transactions in some way. The security method that's gained the most support in the Internet community is encryption, where the data sent over the network is scrambled in some way at your computer before being sent to L.L. Bean or whomever you're buying from. The computer at L.L. Bean knows how to unscramble the data, so once it receives what looks like unintelligible garbage from your computer it can decrypt the data and extract your shirt size, desired shirt color, address, and credit card number. But if L.L. Bean knows how to decrypt that data, doesn't everyone—couldn't anyone intercept the conversation and decrypt your credit card number? Yes, everyone knows how to decrypt the data, but there's a key decryption ingredient that L.L. Bean knows that others don't: L.L. Bean's private key, a kind of password. Here, a key isn't a physical thing like your house keys or car keys; rather, a key is a very long string of digits. A computer can combine that string of digits with your message and produce that unintelligible garbage that I mentioned earlier— that's how encryption works.

Page 152

Internet security uses two of these numeric keys. One is called the private key; only L.L. Bean knows its own private key. The other is called the public key; L.L. Bean tells that to anyone who asks. The public and private keys are an interesting pair in that any data you encrypt with the public key cannot be decrypted with the public key; rather, data encrypted with the public key can only be decrypted with the private key. Likewise, data encrypted with the private key can only be decrypted with the public key. So after you fill in your credit card number and click on the button labeled "complete this sale," your Web browser (probably Netscape Navigator or Microsoft Internet Explorer) says to the L.L. Bean computer, "Please tell me your public key." The L.L. Bean computer does that, and your Web browser takes the data it's about to send and encrypts it using the L.L. Bean public key, then sends the shirt size, color, address, and credit card data. If someone were to listen in on the conversation in some way, they would only learn L.L. Bean's public key and a bunch of unintelligible garbage. At L.L. Bean, the computer knows the private key and easily decrypts the data, and the shirt is sent along to you. But what if someone really wanted to take that unintelligible garbage—the technical word is cyphertext—and figure out how to decrypt it? Well, L.L. Bean's public key is just a number, so someone could just write a computer program to try decrypting the cyphertext with every possible number within some range; that wouldn't be all that difficult a program for a hacker to write. Computers are extremely good at repetitive tasks. What keeps hackers from doing that is the length of the key. Different systems use longer or shorter keys, but the shortest key length around yields 1,099,511,627,776—over 1 trillion—possibilities. It's called a 40-bit key. While computers are fast, trying each one of a trillion combinations takes a long time even for a fast computer. But how long is a long time? As you know, computers just keep getting faster and faster. Ten years ago, the idea that a desktop

Page 153

computer could crack a message encrypted with a 40-bit key was ludicrous; cracking such a message would take years. But not any more; people have demonstrated that a group of normal desktop PCs working together can crack 40-bit encryption in hours. The answer? More bits, a more complex key. That's why encryption systems have in general moved over the years from 40 bits to 56 bits (72,057,594,037,927,936, 72 quadrillion possible keys) to 128 bits—128 bits offers over 34,000,000,000,000,000,000,000,000,000,000,000 or 34 decillion possible keys—more keys than there are atoms in the universe! Certainly one day computers will be able to crack a 128-bit key, but it'll be a good long time from now; even if we assume that computing speed will continue to accelerate, it's reasonable to say that 128-bit cyphertext will be safe for at least fifty years. So what's the big deal, then? Why not just move to 128-bit encryption? Because the U.S. government doesn't like it. In World War II, we gained a decisive advantage in the Pacific early on because we cracked the Japanese cryptographic code and so were able to intercept and decrypt many of their military communiqués. German codes were much more difficult, but eventually the British mathematical genius Alan Turing broke the Enigma code, greatly easing the European war effort. The cryptographic experience of World War II led Congress to pass laws recognizing the importance of cryptographic equipment by defining it as munitions—weapons of war. That's important because all export of munitions is regulated; you can't export bombs without the government's permission, and you can't export cryptographic software without the government's permission. Thus far, the U.S. government only allows software companies to export 40-bit software. Holleyman explains that selling 40-bit software is a problem. "It's an absolute bar to that market. There's no limit to what we can sell in the United States, but we can't sell more than 40 bits of encryption outside of the U.S. market without a special license. The global standard was 56 bits but it's quickly becoming 128 bits. We sell

Page 154

40 bits, it's all the government will allow. So yes, there's a very real threat. BSA members are perceiving that they are beginning to lose sales and it'll become more significant in a very few years. "This is the second big wave of PC software buying that's occurred, and it's really network based. And those security features will be built into traditional applications. As consumers are beginning to make those buying decisions, where security is a fundamental component, U.S. companies can't meet that demand. There's always been a risk, and now there's a very real risk today. Have we lost those markets? No. Have we given up on those foreign markets? No. But is there a potential that we could lose the U.S. lead in this area? Absolutely." Products like Netscape Navigator and Microsoft Internet Explorer have encryption software built in so that they can accommodate secure transactions on the Internet, but they come in two flavors: the domestic version, which uses up to 128-bit encryption, and the world version, which can only use up to 40 bits. (Recently they've upgraded to 56 bits.) That poses problems for software distribution and raises costs for software vendors (and ultimately for us). Holleyman's point is that in a very short time encryption will be built into all software, and if all we offer is 40-bit encryption, offshore markets will just pass us by. The government's position on 128-bit encryption is a bit silly. Once, building longer keys into cryptographic equipment was difficult. More complex crypto was harder to break but also a lot harder to make—crypto devices consisted of gears and wheels. An American manufacturer that figured out how to build better cryptographic equipment had made a significant advance in technology, and perhaps an advance that we wouldn't want to share with the entire world. Once cryptographic equipment became largely computer programs, however, much of that argument no longer made sense. The difference between a 40-bit cryptographic program and a 128-bit cryptographic program is trivial. Why, then, is the government trying to keep 128-bit programs out of the hands of people outside of the

Page 155

U.S? Because it wants to be able to spy on communications between Americans and foreigners, and, again, cracking 40-bit cyphertext is possible for the National Security Agency's supercomputers. It would be sad if, in the process of trying to watch its own citizens, the U.S. ended up impoverishing itself. The End Of Innovation? Moving From Technology-Driven To Market-Driven The automobile industry struggled for decades to make a reliable, easy-to-drive car. Eventually it reached that goal, and once that happened, as you've already read, the automobile market had a tough time selling cars on the basis of innovation or technology. Detroit moved from being technology-driven to being marketing-driven. Could that be happening in the most vital part of the computer world, the PC hardware/software market? Are we seeing a performance plateau in desktop computers? Most people would say that we're not nearly finished, that there's much faster hardware coming and concomitant improvements in software as well. But I'd dispute the point, having watched the growth of desktop microcomputers since the early '70s. Before 1984, microcomputers had existed for ten years but weren't commonly used in corporate settings because of a lack of software and resistance from the existing Information Technology (IT) managers. But enough software had appeared by 1984 to make PCs an irresistible addition to any knowledge worker's desk, and the change was dramatic. Prior to PCs, you'd generate a memo either by typing it yourself or vying with others in your organization for the services of the typing pool. Getting a twelve-page memo out was a minor production. Numerical projections and ''what if'' analyses involved long hours with calculators and columns of handwritten figures. PCs changed

Page 156

all that with word processing and spreadsheet software—it was an undeniable productivity "win." But PCs weren't very easy to use, and so many people avoided them. In the late '80s, PC software changed in two ways. First, most companies networked their PCs, making e-mail and electronic document sharing possible within a company. Second, PC software became more graphical with the advent of the mouse and Windows and Macintosh software. This graphical user interface or GUI (pronounced gooey) software made computers easier to use and so won over many of the PC-fearful. GUIs also made moving data from one application to another easier, so that, for example, one could grab a bunch of numbers from inside a spreadsheet and insert them as a table inside a document without needing to be a rocket scientist. This GUI revolution was a kind of "second wave" of PC software and, like the first wave, it brought increased productivity because it appealed to more people and therefore extended the benefits of desktop computers to a wider share of the populace. Simplified data sharing also yielded some productivity gains. But the second wave's productivity gains were nowhere near as large as the first wave's, nothing like the quantum leap afforded by moving from pencil and paper to a computer of any kind. GUI software has evolved into newer versions of Windows: Windows 3.0 arrived in 1990, Windows 3.1 in 1992, Windows 95 (which is really Windows 4.0) in 1995, and Windows 98 in 1998. Improvements were offered—things that the previous Windows didn't have—but fewer and fewer of those improvements came with each version. The result? Virtually everyone using Windows 3.0 upgraded to Windows 3.1. Many, but not all, corporations moved from Windows 3.1 to Windows 95. To this day, there are thousands of folks still running the 1992 model of Windows and quite happy with it. Windows 98 has seen an even smaller adoption rate. The reason for this is simple and parallels the automobile case: desktop computers burst onto the field years ago, offering a wonderful

Page 157

ability to help us get our jobs done. They improved with time, but at a diminishing rate, just as with automobiles: the difference between a 1919 and 1959 automobile is far greater than the difference between a 1959 and a 1999 auto, as car technology has plateaued. Beyond Fins There's nothing wrong with this leveling off of technological innovation, either in cars or in computers. In fact, one side effect of things slowing down in a technological field is that the players finally have time to stop and assess where their industry has gone. It's not coincidental that automobile safety became an issue once automotive technical advances cooled off; perhaps a slowdown in computer technological innovation will allow developers to notice that, when they run out of new features, quality could become a selling point, as it did in cars. Of course, some automakers responded to the lack of new technological features by just adding fins to their cars. Let's hope the software industry comes up with a better strategy. Expecting constant technological improvement is a significant part of understanding the computer business, according to Dr. Ken Flamm, a senior fellow at the Brookings Institution and author of Creating the Computer: Government, Industry, and High Technology (Brookings Institution Press, 1988). Dr. Flamm had this to say when I asked him about the role of technological change and the software market: "The key economic fact that dominates the computer business is this exponentially cheapening price curve. Semiconductors 30 percent a year, computers 25 percent a year. PCs drop in price about 30 percent a year, taking into account quality changes. There's not been anything like this in our experience for decades. So the bottom line is, every three or four years there's an order-of-magnitude decline. New markets open up. Things that would not make sense in the past all of a sudden make sense when the computer itself costs one-tenth

Page 158

what it used to. In my opinion, the history of the computer is a history driven by this fundamental technologically driven fact. Computers are typically quite price elastic, around -1.5, meaning that a 10 percent decrease in costs leads to a 15 percent increase in sales." Now, everyone knows that there's a limit to how much faster computers can get; no one argues that. But most people feel that we're not anywhere near that limit, and they're probably right. Arguing that computers won't get much faster is silly. But, again, arguing that PCs won't get much faster may not be. At the heart of every PC is a chip or a set of chips called a central processing unit (CPU). In some ways, you can think of the CPU as doing for a computer what an engine does for a car. But whereas nearly every engine on the market uses the same kind of gasoline, different CPUs are as dissimilar as night and day. You may know, for example, that you can't buy a program for a PC and run it on a Macintosh or vice versa. That's because the PC and the Mac are built around different CPUs. CPUs are differentiated by a number of characteristics: maximum speed, the amount of data they can manipulate in one operation, and the amount of megabytes of memory they can access. Maximum speed is measured in megahertz and ranges from 4 to 650 in value (the bigger the number, the better). The amount of data the CPU can manipulate in one operation ranges from 16 to 64 bits; again, bigger is better. The amount of megabytes of memory the CPU can access ranges from 1 to 4096. Megahertz is important because in general bigger numbers mean faster computing. Data width is important because the more bits a computer can handle in one operation, the faster it'll be. And memory is important because more complex software requires more memory; it would have been impossible to fit something like Windows 95 into just 1 megabyte of memory. Intel's first CPU in the PC family was called the 8086. Introduced in 1978, this chip could handle 16 bits per operation, far better than other CPUs of the time, which could only handle 8 bits. Its maximum

Page 159

speed of about 5 megahertz wasn't bad for the time, about five times faster than the then-popular Apple II computer. And its ability to access up to 1 megabyte of memory was impressive as well—the Apple II could only use one-sixteenth that amount. The 8086 had a lot of oddball design quirks, but its greater speed, wider data, and bigger memory capacity made it a hard chip to ignore, and in 1981, IBM released its PC, built around a somewhat slower, cheaper version of the 8086 called the 8088. IBM sold the PC with an operating system named PC-DOS, built for IBM by a then-small firm named Microsoft. 1981 also saw the release of a new CPU chip from Intel, the 80286 or "286." The 286 sported a 16-bit data width like the 8088/8086, but was capable of higher speeds, up to 8 megahertz, and a staggering amount of memory capacity—16 megabytes! The 286 seemed amazingly great: in three years, Intel doubled the megahertz and increased the memory capacity by a factor of sixteen. The increased memory capacity was perhaps the most exciting aspect of the 286, as one of the most popular uses of a PC was (and still is) running spreadsheet programs. Spreadsheets tend to grow, and many users were finding uses for spreadsheet programs that led to spreadsheets that had trouble fitting into the PC's 1-megabyte memory capacity. In 1984, IBM released a version of the PC, called the AT, that was based around the 286. Although the AT was expensive, so-called "power users" flocked to purchase it, only to find something very disturbing: they could buy that extra memory and put it in the AT, but their programs couldn't use the memory. People joked at the time that all the extra memory was good for was just to heat the room, as chips warm up when you use them. What the computer public eventually learned was that the 286 did have some great new features, but that activating those features would make the 286 unable to run PC-DOS (and all of the DOS programs, including those spreadsheets). In designing the 286, Intel realized that there was no way to make the 286 substantially better than the 8088/8086 without making the 286 incompatible with the 8088/8086.

Page 160

And had Intel done that, it wouldn't have sold a single 286—a fast chip's no good without software to run on it. Much-needed innovation versus reality-required 8088/8086 compatibility—what to do? Intel's developers decided to have their cake and eat it too: they gave the 286 a split personality. Start up an AT, and all you had was a fairly fast 8088/8086. No big memory capability. This disappointed users, but IBM assured them that there would be an operating system to exploit the full power of the 286 in no time. "No time" turned out to be nearly six years. On 22 May 1990, Microsoft released Windows 3.0, the first successful mass-market operating system that exploited the 286. Five years earlier, Intel had released the 80386, with a data width of 32 bits, maximum speed of 33 megahertz, and memory capacity of 4096 megabytes. Once again, Intel had innovated with the 386—but if you bought a 386 and ran DOS, your computer "dumbed itself down," so to speak, to a merely fast 8088/8086—16-bit data width, 1 megabyte maximum memory. It took over ten years after the 386's release for a mass-market operating system to appear that fully exploited the 386, when Microsoft released Windows 95 on 24 August 1995. Intel continues to look into building faster and more capable chips. But the company is now the victim of its own success. Currently Intel is working on what is essentially the "80786" chip, code-named "Merced." Supposedly it'll do fantastic things: run at over 600 megahertz, access even more memory, have a 64-bit data width. But in the end analysis, it doesn't matter how powerful it is, if it doesn't maintain what people in the computer industry call backward compatibility with the 8088/8086, Intel won't sell even one of them. Now, the Intel folks are pretty smart. But back when the fastest chip they could build ran no faster than 133 megahertz, the people at Digital Equipment Corporation were turning out a CPU called the Alpha that had a 64-bit data width and ran at 450 megahertz. How come Digital could do this and Intel couldn't? Simple: the Alpha was a brand-new chip. When Digital's people sat down to design it, they

Page 161

started with a clean slate. In contrast, every time Intel starts working on a new CPU chip, there's always that 8088 backward compatibility albatross hanging around its neck—if it comes out with a CPU that doesn't run somebody's 1982 DOS version of Frogger, Intel will be lambasted. There's an old joke in the computer business that goes, "Why was God able to create the universe in just six days? Because he didn't have an installed base to support." Success is a problem for successful hardware vendors, sad to say. Nowadays, Digital has its Alphas up to 650 megahertz. Intel is struggling to catch up, but no one doubts that Alphas are faster than Intel chips like the Xeon, Celeron, or Pentium III. The result is that as long as we remain on the Intel bandwagon, we must accept slower and slower innovation. Not being able to assume a never-ending string of increases in horsepower on the chip side is new for software vendors. There's a kind of see-saw game that goes on between the hardware folks and the software folks that works like this. Say it's 1985 and the average person has an 8-megahertz computer. There are a few "boutique" computers that run at 12 megahertz, but they're expensive. So a large software developer—let's call the company BugSoft— starts working on its new word processor, BugWord 3.0. The company needs BugWord to have lots and lots of new features to attract people to upgrade, so the programmers add features with a vengeance. But the result is a much slower program. No problem, though—BugSoft's doing well, so it gets 12-megahertz computers for its developers. Ah, now BugWord's running fine on the faster machines! BugSoft releases BugWord 3.0 to a public panting for it. And people start complaining. "It's too slow," they lament. The computer press pins the CEO of BugSoft, who explains that BugWord 3.0 runs fine on a 12-megahertz computer. The press scowls that very few people have computers that fast. "Ah, but soon they will," BugSoft's president says, and essentially he's right—for the last twelve years or so, we've been obediently pulling out our wallets and buying faster hardware every year or so. Essentially the software industry

Page 162

writes a check hoping that the hardware industry can cash it or, as one wag put it, "Intel giveth ... and Microsoft taketh away." But what happens when Intel can't give, at least not as quickly as before? Software firms won't be able to keep wasting CPU power and memory on useless features. In an environment like that, what would sell? Perhaps reliability. Perhaps a less scattershot feature set. We've put up with increasingly CPU-wasteful software simply because, as Dr. Flamm observed, the computer power keeps coming, and it keeps coming cheaper and cheaper; we've had CPU power to burn. But in a time of more slowly increasing computer power, it could be that fewer features, smaller size, and reliability might be the winning ticket. And it might be the winning ticket not only for the software industry, but for the entire U.S. economy as well. The biggest win of all would be solving the software quality problem. But it doesn't look like that's going to happen without a bit of nudging from us consumer types. In the next chapter, you'll get some nuts-and-bolts suggestions about how to fight back and help make real change happen. And it doesn't even require a lot of effort.

Page 163

Chapter 6 Fighting Back: How to improve software

Page 165

Reliable software is important, vital to our lives—and you can be sure it'll get more vital rather than less so. Whether it's embedded software like a program in a car or a desktop productivity application like a Web browser, it's more important that it be good than to be flashy. While people's lives don't depend on word processors the way they do on fuel injectors, a word processor crash can waste your time and, if it happens at the wrong time, could cost you your job or perhaps a client. It's time for quality. But how to make it happen? There are many ways, actually. Demand Quality... Or Maybe Just Ask For It! Believe it or not, it seems that the simplest and most effective way to get bugless software would simply be to ask for it. Whether speaking with software industry executives, journalists, software quality experts, or experts in software law, I consistently asked a question along the lines of, "When will software be as reliable as an elevator, as getting a good meal in a clean restaurant, the roof on a building?" I pretty much always got the same answer, which ran something like, "Well, we could do it if you customers wanted us to, but it doesn't seem like customers care about quality." Marc Sokol is Computer Associates' senior vice president for advanced technology—essentially CA's head techie. He very helpfully shared his insights on quality in shrink-wrap candidly. (CA isn't really in the shrink-wrap desktop productivity applications market, so Marc didn't have to worry overmuch about making someone in the company mad.) He initially said about reliability, "I'm not sure it'll ever happen. Software has so many moving parts, so to speak, that it may never be

Page 166

that reliable. You can't compare a $200 shrink-wrap word processor with, say, a $200 microwave oven as you suggest [I'd offered the comparison of a $200 microwave oven being so much more troublefree than a $200 word processor] because there's so many more moving parts, probably two or three orders of magnitude more.'' Then he thought some more and said, ''Software can be made more reliable, as in the stuff the military or space creates, but it's done with a tremendous amount of belt and suspenders. It's not fault-free, just very redundant. That redundancy sort of allows the software to 'self-heal.' " Can't that be done to commercial software, I asked? "Sure," he replied, "but who'd buy it?" He reckoned it would cost about 50 percent more to build in reliability, and so such software would be priced out of its market. So he was saying that he felt that commercial software could be better, but reliable software wouldn't make any money for the developer? He agreed, saying, "You've got a word processor with less features but it doesn't crash versus this other guy who's got lots of neat features, it's not going to sell very well." But is that true? Remember those 20 million users of Word. Charge them an extra buck and you've got $20 million to spend on quality, right? "Yeah, but [that] market's not quality sensitive. You try to take on some market leader with higher quality. Can you charge more for it? I don't think so. On the other hand, if you're talking about database software, like Oracle, Informix, Sybase, SQL Server, in that market quality's important. The example I like to give is sort of mainframe versus PC. You look at mainframe software, and there's an area where quality is vital. With mainframes nowadays, if you have one unplanned downtime in a year, then someone's going to lose his job. In contrast, how long do you go on your PC without rebooting? I'm very productive with my PC, don't get me wrong, but I reboot at least once a day." But if the market changed, it could sell? "Sure. At present, there are different markets for computer software. The shrink-wrap market is

Page 167

very high feature, lower quality. You could see more quality—but, again, would the buyers be willing to pay for it?"1 When talking with Sybase's then-CEO Mitchell Kertzman, I asked him about what would be necessary to see quality become important in the software market. "It won't change," he told me, "until consumers make it change. That's the fact. The consequence of PC software failing isn't usually life threatening, so you don't get the level of outrage you would if cars were blowing up." But he followed that up with an interesting and very candid remark: ''Now let me hasten to say that if we decided to take that step, if I said, 'Sybase is going to be that company. Sybase is the company that's not gonna make you tear up the streets and instead is going to make what we've already sold you work,' my fear would be that in the current buying environment they'd buy from my competitors, who keep effectively creating discontinuity [he refers here to firms who constantly ship new versions in an effort to keep people wanting to upgrade] and marketing it as progress. It takes a pretty brave company to step out there right now. But I think there's an opportunity there.''2 I tracked down a former CEO of a large shrink-wrap software company who agreed to talk on the condition that he not be named. Let's call him Mr. S., and hear what he's got to say: "The challenge in quality in software is not an easy one. It's tied to processes, how things are done, how things are updated, how quality assurance is handled. A lot of people have talked about how to write software, but very few have talked about how to test software. I think it would be possible for any company, say for Microsoft, to create software that's more solid. I think what's happened is that the market hasn't required it. [Emphasis added] "In other words, if your microwave oven has a bug in it, then you're probably going to return it. With software, it's not like that. People are more interested in getting Netscape Communicator Version 4—the latest thing—than they are in getting a solid version of Netscape Communicator. It seems that the customers have gotten

Page 168

used to having software crash. It's unfortunate—I know for firms I've been associated with, we have higher standards of quality than many firms. The bottom line is that this is a kind of customer-driven thing. There is no reason why software couldn't be five times more solid—of course, it would mean that the next version of Microsoft Office would take 12 months longer to get to market. But since Microsoft shipped Office when it did, with a higher level of bugs, and customers are buying it, I guess the market has voted with their feet. That's what's going on... Microsoft is the epitome of the success of' 'ship early, buggy, and often,' and they've succeeded. "I think [one reason why people tolerate buggy software is that] there's a difference between reality and perception. People say, 'Well, there's bugs in Microsoft software, but they'll fix it and we'll download the fixes off the Web.' It lets Microsoft ship at that speed and what happens is that other companies must compete with Microsoft, like Lotus or Corel, and they have to ship at that rate of speed also." I asked him if lower-defect software has to cost more money. "It's a question of time. In software, my rule is that there's three things in software: quality, features, and schedule. The problem is that you only get to pick two. If you choose features and schedule, then you have given up control of quality. If you pick quality, then you've got to sacrifice either features or schedule, and none of the companies are willing to sacrifice those two. At my previous firms, I systematically picked quality, and that's made some of those products as successful as they were. I'd say to people, 'There is no option but to pick quality.' "If, like most competing companies in the packaged software industry, you pick features and schedule, that leaves out quality. Many times at my previous firms we set schedule aside and focused on quality. We're not the only ones who did that, either—Motorola, for example, does the same thing. But on the other hand, look at how Microsoft Office 97 sells. It's buggy and the trade press said, 'Don't buy it,' but people are still buying it. They just shove it down people's throats and get away with it—but that's not really Microsoft's fault, in

Page 169

a sense: after all, if Ford could ship without any concern for quality, shipping cars six months early that are lemons and people would buy them anyway, then Ford would probably do that. Are they [Microsoft] doing the wrong thing? It depends on how you look at it. Microsoft is the most profitable company in the world, with the highest market cap in the world, Bill is the richest person in the world by far, and obviously it works for them. They have become the model in the industry in how to do it. As long as customers will buy junk, they'll get away with it. And in the end, the victorious generals will write the history. Ten years from now, people will think that Microsoft invented the computer, browsers, the Internet, and that software should be buggy and bloated." 3 In my conversation with Brad Chase of Microsoft, I asked if he could imagine a large firm like Microsoft selling a version of software that has no significant amount of new features, but with all the bugs squeezed out of it. Would such a package sell? His answer was instructive. "No way. We sold something called MS-Write on the Mac, a lowfeature word processor. No one wanted it."4 Hmmm ... sounds like the idea's been tried and demonstrated to fail. But, I asked, was it particularly reliable? Did it have fewer bugs than the competition? Brad's answer: "Well, I'm not sure. But I'll tell you something: no user ever said to me, 'Give us less features.' " Maybe because Microsoft hasn't ever offered no-bug software as an option. As software quality expert John Horch said to me, "I hear day after day that the user ... doesn't know what he wants—I disagree. The user doesn't know what's available. Someone goes into a car lot and the salesman says, 'What options do you want with the car?' and the buyer doesn't know, so he says, 'What do you have?' He may decide that a light in the glovebox is worthwhile, but a light in the trunk isn't. But he's got to know what his options are. So if users don't know that quality is an option, they won't ask for it."5 Debby Meredith, Netscape's vice president for client applications—she oversees Netscape Navigator development—spoke openly about quality and what Netscape perceives customers want.

Page 170

"Shrink-wrap software is still chasing the changing market of end-user demands. [Netscape] only does well if we respond to customer needs, and we are starting to hear that quality is important—but [customers] also say that they need this feature. It's a balance, a trade-off. New features will be less stable, more unreliable than the later versions. Our customers are more sensitive to deployment, infrastructure, security needs. We spend more focus and testing time on things with higher exposure, higher bang for the buck. It's a balance. Our expectation isn't that any one given release is perfect and has zero bugs—but if that was our goal, we could accomplish that [emphasis added]. There are ways to measure that and ways to make that happen. But that's not the balance that our customers are asking for." [Emphasis added.] Later on, Debby returned to the idea. "We are hearing about quality more. Just a few years ago, when the industry was more nascent, it was just 'features, features, features.' Now we're getting to a kind of 'sweet spot' of features. In the longer term, we've got to put a high value on quality but have the business judgment to have the right balance between the market quality and the feature set, and that's sort of the day-to-day challenge that we face as software managers." Debby went on to opine that this was one of the biggest challenges that a software executive faced: ''Every day, we evaluate the schedule/features/resource trade-off and hope to get that right."6 Microsoftian Tom Campbell isn't one of the higher-ups, he's more of a techie. He is the program manager for Visual Basic for Applications, an important part of more and more Microsoft applications. We spoke at length about quality and how the "dial" gets set between features and quality. Tom's is a somewhat in-the-trenches perspective of Microsoft, and here's what he had to say: "First of all, we don't look at features, we try to solve problems." So could we say either choose to solve 420 common problems or 100 common problems, and spend the rest of the time shaking out bugs? Tom agreed. "All right, in that case, sure, we could produce code with less bugs. If the market realigned itself to focus on bugs rather than

Page 171

features, then we definitely could produce code with less bugs. And we'd do a better job of it than anyone else on the market." "But," he stressed, "understand that we don't rush things to market. No one has ever put pressure on me to get a product out. I've gotten pressure to produce a great product, not one on time." Other Microsoft people have claimed that to me as well. In a conversation at a press reception, Jon DeVaan, the Microsoft VP for the Office products, agreed. He said to me, "Something that I really like about being at Microsoft is that we don't set our ship dates based on what marketing tells us. We work until we get a certain quality and then we ship."7 Tom returned to his assertion about quality. "We do a pretty good job all in all; we have found hundreds of bugs that our users never found." But do they all get fixed? "We have to triage. We can't fix everything, so we make judgment calls on what gets fixed. In the case of Visual Basic 4, we published the list of known bugs when we shipped the product." He seemed to be searching for a good example of too much bug-stomping, and found this one: "I knew a guy at NeXT [a computer venture backed by Apple founder Steve Jobs that failed], and he said NeXT would spend just forever trying to get something perfect. But what ended up happening was that they just didn't release stuff very often. And people just didn't buy stuff very often. What Microsoft is good at is writing software that people want to buy." So how do you set the dial between "problems solved" and "bugs"? "We don't; customers set the dial. I once heard someone say that at Microsoft, we're more of a sales-driven company than a customer-driven company." DeVaan also said something like that; when I asked him, ''So you set quality based on some perception of what the market is willing to pay for, right?" he responded, ''In a sense, yes, I suppose." But when I asked him, "Do you think there'd be a market for a different line of products that have a frozen feature set but that are as bug free as possible— software for a different market segment?" he looked sort of puzzled and replied, "I don't know; it's an interesting question."

Page 172

Tom agreed that a market with cleaner software would be desirable, but as with other software industry insiders, he still wasn't sure it would sell. "Safer software makes sense—there's a reason why I drive a Volvo. But," he noted, "there are 270 million people in this country and only 2 million of them read Consumer Reports." Ed Yourdon is one of the world's leading software gurus. It's not outlandish to assert that most professional programmers have read at least one of his books. Originally he wasn't so sure that he agreed with my assertion that shrink-wrap software quality should be better, so I asked him, "you're a writer. Do you trust Microsoft Word as much as you trust a pad of paper and a pen?" As it turned out, I asked the right question. He laughed loudly and replied, "I just finished the first draft of a book that I'm writing about the year 2000, in Word 97. Not only have I abandoned Word, I've abandoned Windows altogether and gone back to the Macintosh thinking that would be more reliable. I just spent six hours yesterday trying to get Word 6 for the Mac up on Mac OS 8, so I'm very much aware of reliability. Word 97 clobbered my manuscript six or seven times. The master document feature completely destroyed the manuscript." So is it reasonable to expect quality in shrink-wrap software? "It's certainly not unreasonable for a concept like a word processor—it's not a new intellectual concept. We've been doing word processors for over twenty-five years or so, so you're absolutely right, it's not unreasonable to expect it and ask for it. Part of the question is whether you're likely to be seduced by the new features that Microsoft keeps throwing into the new versions. If they come out with a Word 98 and nobody shows up to buy it—actually, that happened with Word version 6 on the Macintosh. It was so bad no one bought it, and Microsoft had to scramble to get the next version out with useful features. In fact, you can still buy Word 5 to the Macintosh. Ultimately, it'll be incidents like this which will make software better. If you go to a restaurant and find cockroaches on the wall, well, first of all they won't get much business, and second, the health department

Page 173

will probably come shut it down. It's the reaction in the marketplace that will ultimately bring change on the part of the owners. In software to drive an elevator, I think it makes sense to have licensing authorities, regulatory bodies, and that sort of thing. Presumably you won't die from a bug in the word processor, though, so I think it will be marketplace pressure that will cause a change." Ed had another thought as well: "Perhaps the equivalent of a Consumer Reports for bug tracking, putting something like that up on the Web would be terrific. I don't know who's going to finance it, but if every PC user paid a dollar a year for that information, wouldn't that be worth it? You'd think that there are enough users of Microsoft Word, to use that for an example, to support an independent guy who'd compile a list of known bugs and deficiencies and if I had access to something like that I might have saved myself six hours the other day. "I think those of us who've been in the computer field for a while and know what the potential quality of software can be perhaps get a lot more frustrated with this than the average user, who may think, 'Well, this is the way God intended it.' "8 He was very surprised to hear that something like that list of deficiencies, called BugNet, already exists. We'll hear about it later in this chapter. In most of these interviews, the conversations were frank and open. I generally wasn't getting guarded, "Tell the journalist the politically correct line" responses. Folks like Marc Sokol and Debby Meredith actually sounded intrigued by the notion that their firms could take on the competition with a new "secret weapon," so to speak, as did Steve Madigan of Microsoft, who's been quoted elsewhere in the book. So perhaps all we've got to do is to make clear to vendors that we want quality. One way to do that is with a letter. Regular old paper letters are far more effective than e-mail or phone calls, and if you don't have much time to spend composing, one, try something like this:

Page 174

November 6, 1997 Joe Manager Bugsoft, Inc. One Bugbite Way Anytown, CA 89891 Dear Joe Manager: I have received your solicitations offering version 4.1 of your BugWord word processing product. I will not be purchasing it, and wanted to explain why in the hopes that you will incorporate my concerns in your next version. I currently use BugWord 4.0 and in general find that it meets my needs. I upgraded from BugWord 3.5 not so much for its new features (although the built-in HTML editor is convenient, thank you) but in the hopes that the Master Document feature, introduced back in version 2.0, would finally operate properly. Unfortunately, despite hours of work and $100 worth of for-pay technical support with your staff, it still does not function well. And that underscores what I'm asking for in the next version of BugWord: reliability. I'm sure it must be difficult for your firm to scour the user community looking for the next great "killer" feature; surely after all these years, most of the cream of the feature list has been skimmed. May I respectfully suggest that you consider not adding any features, or only a minimal list of features, and instead produce a version in which everything works, all the time? You could call it the "bulletproof," ''nonstop," "fault-tolerant" version, or something like that. I know that many "bugs'' that people blame on you are actually failures in their computer's hardware, operating system, or driver programs, and that in some cases simple user error is at fault. But some BugWord failures lie inside BugWord itself, and that's what I'm asking you to improve. I'm asking you to make the world's best word processor also the world's most trusted word processor. Please consider my proposal for your next version, and best of luck to you and your staff in your ongoing development efforts. Respectfully,

Page 175

Your letter would look different, but the themes are the same: • State your objective early. Like all businesspeople, software folks are busy. • Keep it short. Ditto. Less than a page. Don't go off on a rant. Avoid sharing your favorite conspiracy theory about Microsoft's evil plan to dominate the universe, whether you're writing to Microsoft or one of its competitors. • Be polite. Nobody likes being yelled at. Big software companies are already profitable and successful. They feel that they don't need to read your letter; don't give them an excuse not to. • Mention a particular chronic bug. The idea here is to shift people's priorities away from features and toward bugs. Understand that the person who reads the letter is likely to be an executive or marketing person. He's probably sufficiently removed from the nitty-gritty of coding that he may well have convinced himself that there are no bugs there to begin with. I'm constantly amazed at the product managers who will look me in the face and say that there are no bugs in their product, and what am I talking about anyway, when their own companies publish multipage bug lists. Be specific, and only discuss one or two egregious bugs. Do not make general statements about how buggy the program is, as this sounds like name-calling; ever had someone complain that there's some "general" problem with your work, only to be unable to name any but a few lame specifics? Make it clear that you'd buy the product even if it had no new features, but didn't ever crash. Don't get nuts here and list your twenty most annoying bugs. And, again, be polite. • Make it clear that you know bugs come from other sources. The number one excuse I get from software executives is that we users are all dodos that don't understand that some problems come from the hardware we buy, the driver programs for that hardware, and the operating system. "What is a bug, anyway?" I get asked by software people all the time, as they hope to confuse

Page 176

the issue. But there are bugs that are specific to applications, and you should make it clear in your letter that you understand the difference. (Reread Chapter 2 if you're not clear on the difference.) If the Table Wizard in BugWord doesn't work, it's not a driver bug, it's not bad hardware, it's the Table Wizard. If you run five different programs on a regular basis and only BugWord crashes with a General Protection Fault, that kind of points to BugWord. But in any case, add a sentence about bug sources like the one in my sample letter. And have I suggested how important it is to be polite? If It's No Good, Send It Back Just purchased a new version of a piece of software and the vendor hasn't taken quality to heart? Send it back. We did. When Office 97 appeared from Microsoft, I decided to buy it for my company. The main plus of it was a mail client/scheduler package called "Outlook" which I'd been running in its beta form for a few months, and while it wasn't the last word in such programs, it had a good look to it and so I wanted my staff to have it. We ordered twenty-five upgrades of Office 97, one for each employee. They arrived and we were about to start installing them on our systems when I noticed that Outlook advised that you have 32 megabytes of memory on a computer in order to run Outlook. At the time, 32 megabytes was an unusually large amount of memory, and many computers in our company didn't have that much memory. Furthermore, the idea of 32 megabytes just to run a silly e-mail program seemed ludicrous to me. (Now I call the program "Look out!" because that's what I do whenever someone suggests using it.) A closer look at Office 97 revealed that Word 97 could not write out files in Word 95's file format: in other words, once you read one of your old Word 95 files into Word 97 and saved that file, the file would be in Word 97 format, unreadable to anyone with Word 95. This was

Page 177

clearly a sneaky way to urge me to upgrade all of my machines. But many of my magazine and book publisher clients weren't using Word 97, they were sticking with Word 95. Twenty-four of the twenty-five boxes of Office 97 we'd purchased still had the shrink-wrap on them, so we sent them back to the dealer who sold them to us, and, of course, I wrote a letter to Microsoft explaining why we'd chosen to return the product. Yes, it is a pain to stop using a software product after you've used it for a few days. You've got files now that only that program can read, and it's a pain to go find the old version and reinstall it. But if an automaker told you that it was selling you a four-door car and the car only showed up with two doors, you wouldn't listen very long to an explanation from the vendor that "Really, windows are kind of like doors", you'd send the car back. Think the same way with software: if it doesn't do what the vendor promised it would do, or if it makes you do business their way rather than your way, then send it back. Demand Fixes, Not Upgrades Once you've gotten the technical support person at BugSoft to admit the Table Wizard in BugWord doesn't work, the support person will no doubt offer something like this: "While it doesn't work in BugWord 3.2, which you're using, it does work fine in BugWord 4.0. Why don't you upgrade?" And sometimes the carrot of "It'll work in the next version" is paired with this old faithful stick: ''Because, you know, we're not going to be supporting 3.2 pretty soon." Is there any good reason to upgrade to 4.0? Does it have some killer feature that you really lust after, or are you just hoping that the Table Wizard will be fixed? If it's the latter, then don't buy the upgrade. Be persistent. (But polite.) Say something like this: "Why, thank you for the offer and the information, but I purchased the BugWord 3.2 in the expectation that all of its advertised features would work properly. That isn't the case, as you've agreed.

Page 178

Now, products have defects—that happens everywhere. You buy a car and something hasn't been done right, there's a defect, and you take it to the dealer and they fix it. If you bought a TV with a nonfunctioning remote control, you'd expect the vendor to fix the remote control, not try to sell you a new TV, right? I'm afraid I cannot afford to upgrade my computer with the extra memory and disk I'd need to run BugWord 4.0, much less buy the BugWord upgrade. No, if you would, please just fix the defect in the product that I purchased." Now, I guarantee you that the person on the other end of the phone has no authority whatsoever to promise you a fix. But at least you've responded to his suggestion reasonably. He'll bump you up to his supervisor; tell her the same thing you told him. Just keep working your way up the chain. Get names of the people you've spoken to and their phone extension numbers—it's odd how sometimes a phone conversation that's not going the way a support person wants it to go just gets spontaneously disconnected. Or you may get the "We'll give you a refund" gambit. It goes something like this: you've said you don't want an upgrade. The support person then says, "Well, then you can return the software for a refund." Don't take the bait. "I don't want a refund, thank you. I have already used the software for a few weeks and have invested a fair amount of time in developing documents with BugWord 3.2. If I were to send the package back, I would no longer be able to access those documents, and would have lost entire weeks of work. Would you compensate me for that loss?" It doesn't matter what they say, start climbing up the supervisor ladder. Be polite. Take notes or, if possible, attach a tape recorder to the phone and record the conversation. Summarize the conversation in a letter to the CEO of the software company with a personal plea to fix the defect. If you get no satisfaction (oh, sorry, I meant to say when you get no satisfaction), send a copy to the Federal Trade Commission and your state's consumer protection agency, and file a

Page 179

complaint with the Better Business Bureau. If you have a Web site, put the letter on your site so that others can learn from your experience and possibly even provide suggestions for other strategies. Yes, it's more work. Yes, it takes a bit of time. But software companies are used to getting a free ride. They're used to consumers acting like good little lemmings and jumping off whatever cliff they tell us to. Very few people complain (mostly because most people don't even have an expectation of low-defect software), and so the software firms have no incentive at all to change. Help provide that incentive—complain! Tell The World If you went to all the trouble to actually verify that the Table Wizard doesn't work on BugWord, tell the rest of us. Save us the time of having to figure it out ourselves. First of all, you've received a defective product. If the vendor will not fix it, well, that's what the Better Business Bureau is for. They're at www.bbb.org and they'll take your complaint online. They can't necessarily fix the problem, but they can help others to know what the software vendor has done to you. Many states have consumer protection councils or agencies. Contact your state's consumer protection group. (If you don't know where that is, call your state legislator's office. They'll know—that's what they're there for.) As more and more people complain, they'll gear up to begin action against the shoddyware vendors. Write computer magazines with your information. Some magazines have a "gripe line" like the one that Ed Foster at InfoWorld runs. Again, be polite, remain very factual, don't exaggerate, don't rant, and the chances are good that the magazine will print your letter and help you get the word out. They can't make software vendors help you; all they can do is to pass along what you've told them, provided they have the space.

Page 180

Ask For Fewer Features Following on from the last few points, take note of which features you use in a product. As new versions appear, note whether you really can use them or if they're just worthless doodads. If you're involved with online discussion groups, take an advocacy position for fewer features (and more reliability). When writing vendors, again note that you think that when it comes to features, less is more. When we're talking about mechanical devices, one way we describe the complexity of a device is the number of moving parts. We generally feel that a device with many moving parts is more complex and probably harder to make reliable. With software, start thinking this way: Every feature is a moving part. Some people don't like power windows or automatic door locks on cars because "It's just one more thing that can break." In software, features are exactly the same thing. Don't you think that if automakers could lump thousands of silly features onto a car they would, in the hopes that it'd attract buyers? Of course they would—but they're required by law to build safe products. Software firms aren't. Stop Making Excuses For Bad Software In general, people expect quality. We expect good food at restaurants, cars that don't fall apart the first time you make a tight turn, airliners that don't fall out of the sky. But we don't expect good software. Where did we get that low expectation? Toward the end of our conversation about the FDA's role in monitoring quality in medical device software, John Murray made an interesting observation about people's expectations about software. "From the very beginning, from the first time you started using software, the first time your system crashed and you yelled out, 'Hey, what happened to all my work?', somebody came along and said, 'Oh, that

Page 181

happens all the time.' He maybe didn't say, 'That's okay,' but by saying, 'That happens all the time,' that conditions you to accept bad software."9 If you find yourself in the role of "native guide" for someone trying to make her way through the software jungle, don't assume the role of an apologist for the software industry. Instead, think about saying something like this: "What you just experienced was a defect in [fill in the software's name]. That defect is unacceptable, but unfortunately defects like that are quite common in commercial software. I don't really know why we tolerate defects like this—as I'm sure you know, bugs is the cute word that people use to describe those defects—but we do, and perhaps we shouldn't. We typically cope with defects by trying to figure out where they are and sidestepping them—it's called a workaround. I advise you to keep a notebook of defects in the software you use. When you come across a defect, report it to the software manufacturer. You probably won't get much of a response from the vendor, but if enough people complain, they'll eventually do something. In any case, your best bet is to assume that all software is unreliable at all times. That means that you should save your work regularly when in an application like a word processor or spreadsheet, and that you should back up your data periodically. Some people will tell you it's impossible to write defect-free or low-defect software, but that's not true; there are many examples of defectfree software all around, from big projects like the space shuttle to the fairly large program built into your cellular telephone. But shrink-wrap software developers have chosen to focus on adding new bells and whistles rather than making software reliable. You can help by reminding vendors periodically that you prefer quality to features." It's not a very happy message, but it is a positive one in the sense that you've equipped the novice for the shaky world of software. And if everyone stops tolerating shoddy software, it'll get better. Try to move the language we use to describe software defects to a more useful plane—try to stop using the word bugs and instead say mistakes and defects.

Page 182

Stop Accepting Software Excuses From Others Software will only get better when people's expectations of software quality change. Part of the way you communicate that is, of course, by communicating with software vendors, as you've just read. But we also display evidence that buggy software is okay when we accept it as an excuse. As a matter of fact, software bugs are so accepted that they've become the ultimate excuse. In December of 1996, I was invited to speak at an industry group meeting in Memphis. The flight out was early, and I arrived even earlier, about an hour and a half before takeoff. There were four people in front of me. An hour later, I finally got to the counter. The guy behind the airline counter gave me a "There's nothing I can do" look and said before I could say anything, "Our computers are down—I can't do anything." Now, I was supposed to just nod my head and accept it, sort of see it as the latest version of "Stuff happens." Instead, I asked, "Why are your computers down?" I'd clearly surprised him; if he'd been a computer, I'd say he looked like I rebooted him. So he got his supervisor, who said to me with an "I can explain everything'' look, ''Actually, our computers aren't down. Our communications lines are down." I asked him, "You're talking about your long-distance leased communications lines, right?" He started looking nervous—maybe I knew what I was talking about. He agreed that yes, that was what he was talking about. "That's not possible," I said. "Your network uses lines from AT&T, MCI, and Sprint, and the reason you use multiple carriers is specifically so that even if all of AT&T crashes, you'll only lose some of your communications lines. You're not going to tell me that AT&T and MCI had system failures at the same time?" He brought out his supervisor, who said to me suspiciously, "How do you know what our network looks like?" I explained that I'd been a speaker at a technology conference recently and one of the other

Page 183

presenters had been a vice president from that airline, who went on at great lengths about the redundancy built into the airline's network to enhance reliability. Finally, in frustration, the big boss said, "Just what do you expect me to do about this, sir?" I told him, "You guys are supposed to be safe. I expect you to write good programs, to buy good programs, and to buy reliable hardware and communications gear to back it up." "That isn't reasonable,'' he replied. "How can you expect that?" By now, I had a bit of a crowd, so I notched up my voice a bit and answered, "Well, if you can't keep your computers up, why should we believe that you can keep your planes up?'' What I was trying to get across to them was that software's not an all-purpose excuse. And it's odd to hear this kind of excuse from airlines—after all, they're not going to say, "We're not going to fly because pieces keep falling off of our airplanes," are they? Of course not—people would bolt from that airline. So why do they admit in public that pieces fall off their computer system? Because it doesn't alarm us as it ought to. The incident actually went from bad to worse, by the way, and illustrates how not to use computers in a business. The ticket agent told me that as I already had a ticket, I should go to the gate. I went to the gate and tried to check in. The gate agent said again that their systems were down, so she couldn't do anything. But, she added, I was in luck—I had a paper ticket. "How so?" I asked. She explained that anyone who claimed to be flying on an "e-ticket," one of the new electronic tickets that airlines seem to be so much in love with these days, was simply out of luck. As the computer was down, there was no way to prove that they actually had that ticket. "So you're telling me that the people with the paper tickets will get on the plane, but the e-ticket people won't?" I asked. "Unless some manager tells me to let 'em on, I can't," she answered. So I guess the moral of the story is, use paper tickets. Let's explore this "appearance of sloppiness due to bad software" issue a bit more. Suppose you're considering buying a car from a partic-

Page 184

ular car dealership, so you call them to get their store hours. A receptionist answers and starts to answer your question, but is distracted by something, and at the same time you hear a crashing sound. She explains that the building the dealership is in isn't kept up well, and that was just a bit of the ceiling falling in—it happens now and then. Would you want to work with a firm like that? If not, then how are crashing computers different from crashing ceilings? Well-managed companies ensure that their infrastructures function properly. Computing is part of the infrastructure; we just haven't realized that it should require quality. Poor computing should ultimately be something companies would be ashamed of, just as they'd be ashamed to tell you that you didn't get your package on time because they scrimped on packaging costs and their boxes all fall apart while being shipped. Poorly managed computer systems are just poor management. And you don't want to do business with poorly managed companies. Make it clear to the people that you buy goods and services from that faulty computers reflect poorly on them in your eyes, and that their computer problems aren't yours—"The system is down" is no longer an acceptable excuse. Help The Computer Trade Press Improve When it's time to buy a new computer, many people turn to computer magazines for reviews and advice. The computer press is a huge business offering a wide array of publications from the weekly tabloids like Computerworld, InfoWorld, or PC Week to consumer-oriented magazines like PC Magazine or Windows Magazine to more technical journals like BYTE. No matter which one of those you pick up, there's a good chance you'll end up reading something written by Wayne Rash. Wayne is in some ways the dean of computer columnists. He writes equally well to audiences of techies as to managers and legislators—he's as much at home explaining how high-speed "gigabit"

Page 185

networks work as he is advising IS managers on solving problems of internal politics. He has twice testified before Congress on the political uses of the Internet, and is currently the senior technology editor of Internet Week. He was kind enough to find time to talk with me about the press's role in software quality. When I asked him, "Why don't companies spend more time on fixing bugs and less on adding features?" he had this to say: "It's partially the fault of people like me. Look at [a product review in] something like PC Magazine, you'll see this huge comparison chart. And I probably shouldn't pick on PC Magazine, every magazine does it. Every conceivable feature any product could ever do shows up, and if a package has that particular feature, then there's a little black dot next to that product. What companies want is to have all the little black dots filled in because it makes their software look better."10 So journalists are part of the problem, then. How much of the problem? "We're an important part of the problem. Some of us make the feature matrix the basic thing upon which we judge software." Because it's the central visual feature of most product roundups? "Exactly. The companies then realize that if they have a significant number of bullet points missing, then they'll look bad. This is exacerbated by the fact that marketing managers of software companies have a tendency to set expectations higher than they should be set. Dilbert is all true, believe me. They say, 'This package will do this and this and this,' and they give the engineers a year to accomplish these things when in fact to accomplish those things may take two years or fourteen years or forever." Why don't the companies perceive quality as a feature? Why don't they see quality as a selling point? "Again, it's partially our fault. Writers don't slam products hard enough for bugs. I will—I've failed products over having too many bugs. Unfortunately, very few journalists will."

Page 186

I asked who else contributed to software quality problems, but Wayne remained steady about journalists' culpability in high-defect software. "We don't hold software vendors' feet to the fire as we should. People don't know better; they think that because it's shrink-wrapped software on the shelf at CompUSA, it must be okay. Then they take it back to the office and it blows up. Rather than going back to CompUSA, where they know that nobody's going to pay any attention to them, they just put it up on the shelf and never use it again. One of the difficult things we must be prepared to do is to— well, very few publications are willing to publish really negative reviews." Why is that? "A couple of reasons. First, sometimes the publisher and the editor are the same guy. [In a magazine, it's the publisher's job to ensure that the magazine is making money.] The temptation to kill a story that will end up costing the magazine ad revenue is too great." I related that as a computer columnist for over ten years, my experience is that if I write something negative, I'd better be prepared to defend what I've written, as I'll be called on it. My editors know that vendors will respond to negative writeups, so they've got to be ready to respond to the vendors' complaints, so they contact me and grill me on my claims. But, on the other hand, if I write some frothy positive prose, no one complains. As a result, there's an unconscious influence to write positive stuff, without any influence from the advertising buyers. But I've never been told to tone down a review to make an advertiser happy. Wayne agreed that he'd seen similar things in computer journalism. "I have had editors say to me, 'If the product is that bad, we're just not going to cover it. We really want to publish things that are positive.' And, to an extent, readers don't like negative stuff. But the business community wants to know this, they need to know when something doesn't work. With the consumer market, it's the other

Page 187

story, you don't see much negative stuff. It's the same in the car industry—you don't see too many negative articles in car magazines, although that's changing, perhaps in part because of the comparison to our industry. Look at PC Magazine; I don't mean to pick on them, as they're nice folks and I've worked for some of them in the past, but when was the last [really] negative review you saw, other than comments like that the memory card on some product got in the way of an expansion board?" "One of the most powerful journalistic forces in the general market is Consumer Reports. They don't take ads and they're perceived not to have any biases. That's not true—they have some very obvious biases—but they're pretty good about explaining their criteria right up front before reviewing a product, and you can then use that information to decide how heavily to weigh their opinions. We've got to do a better job identifying bad products. It's a responsibility that we as journalists have not fulfilled properly." I asked him if he felt that there was a market solution to the quality problem. "Consumers must expect better. Again, we journalists must point out where there is no quality—we're the first step. Consumers can't make an intelligent decision if they don't have any information. I'm sure you've seen cases where you saw a defect in a product and a month later it was fixed, because the press reported on the defect. Publicity is a powerful tool. We're the means by which consumers find out about product quality. Take Word 97. We at CMP, my publisher, won't use it because it can't write out files in Word 95-compatible format. Why did Microsoft do this? It certainly wasn't a technology move—the format for Word 95 documents isn't exactly a secret, particularly inside Microsoft—I think Microsoft just saw this as a way to push people to upgrade all their old copies of Word to Word 97. The press reported this deficiency, and people just plain didn't buy the upgrade. Finally Microsoft fixed it—the market can have influence. People make deci-

Page 188

sions based on the information they have. If they didn't know that Word had this problem, then they might have upgraded. "Interestingly enough, the question isn't, 'How do you make companies produce better quality software?' It's, 'How do you get businesses to demand better quality?' And it's a shame. If a CFO of a firm were to find that his manufacturing manager were buying defective parts, he'd go ballistic. In the same way, a CFO ought to go ballistic if his IS manager or CIO is buying defective software. At that point, he ought to say to his IS manager, 'Hey, you're thirty-seven years old, isn't it about time for you to retire?' But CIOs and CFOs aren't insisting on quality. Why don't they? Partly because computing is seen as a cost center and so doesn't get the resources that it needs. But basically, buyers have to have information, and they have to have an alternative. We must have publishers who are willing to make Microsoft mad." Ed Foster of InfoWorld had similar things to say. In discussing what will have to happen before shrink-wrap quality improves, he opined: "Customers have to do a better job up front about the products that they're considering buying. The trade press has to do a better job of reporting to give people that information that they need—and the trade press doesn't do as good a job as it should." Again, I asked, "Why is that? Why don't we do a better job?" "I used to be editor of InfoWorld and we dealt with these issues all the time. For the trade press, you're put in a position where your readers want information as fast as possible when a new product comes out because they have to make a decision and they want you to tell them about that product. And of course, when a product first ships, what can you say about quality? Not enough is know at that point. All you've had so far is beta software. InfoWorld had a policy for a long time of only reviewing shipping products because we wanted to be able to report if a product was buggy, and you're not allowed to talk about bugs on a beta product—vendors say, 'That's not fair, it was just a beta.'

Page 189

"But as time went on, it became harder and harder for us to compete in our marketplace without telling people something when the product first came out. If you wait until you can do a really good job of testing a product before writing about it, you'll be too late, as your readership has already made a decision about the product." I asked him how computer journalism could get better. He felt that the Internet was the key. "The Internet seems to have the promise of making things better. The Internet now is probably the greatest defense that customers have. Every software publisher now has to keep in mind that if enough people get pissed off at them then this will become very well known without any publication having to do anything. On the other hand, the Internet is so unstructured, there's no filter on the Internet—just all of this noise. If we can find ways that this information vehicle can filter through to the essential truth of what people are reporting from their experiences, then there's the potential to solve many of these problems."11 How can you help? Let the managers of computer magazines know that quality's important to you and so you need to know just how good a product really is or isn't. Write a letter to the editor of your favorite computer periodical and urge him or her to print the bad as well as the good. If the magazine gives out ratings of software it reviews, check a few previous months and see if it's given anyone an F, and if not, ask why not. Here, consider using e-mail, as many computer periodicals make heavy use of it. Don't write a generic letter and send it out to multiple magazines; it'll be obvious, will look like mass-market "spam" mail, and it will be ignored. Take a moment and tailor the letter to the publication. Buy publications that tell the whole story, and tell them that's exactly why you read their magazine. Computer writers want to tell the whole story, but don't always feel that they are rewarded for doing that. Your letter can help change that! (But be polite, no one likes to be yelled at....)

Page 190

Get Involved With Beta Programs And Be Vocal Part of the testing and development process for most shrink-wrap software is the beta distribution program. Actually, it's more than just testing and development—it's marketing as well. The idea is this: a company's programmers set to work designing a new package or an update of an existing package. The earliest efforts, the ones that fall apart easily, are kept in-house and tested until they're moderately stable—they'll run for a few hours without crashing. Meanwhile, the company's marketing department has been leaking details of the new software in an effort to create demand for this new version. Customers want to see this new software, and so the vendor releases an early, incomplete version of the software called a beta version. The vendor typically doesn't charge for it, and tries to make the people who've gotten the beta version of the software feel exclusive by not offering the beta to just anyone; rather, a beta recipient must meet some minimum qualifications. In return for the privilege of seeing the software early, the person agrees to act as a beta tester, meaning that she'll put the program on her computer and try to use it. When she finds a bug in the software, she agrees to write it up and report it to the software vendor. The software vendor doesn't promise to fix the bug, it just wants to know about it. Finally, when the beta testing process is complete, the less buggy version "goes gold" and the shrink-wrap version appears on store shelves. Once, beta testers usually got a free copy of the final shrink-wrap program; nowadays that's normally not so, although it still happens sometimes. Once upon a time, there were some very good reasons for a "power user" of a piece of software to get in on the beta test process. Years ago, software vendors hadn't yet developed millions of features in their packages, and as a result the new version of your favorite software might offer an amazingly useful new capability. That new capa-

Page 191

bility often allowed you to do your work in a better way, making the annoyance of more frequent bugs (the common price of using a beta version) an acceptable payment for getting early access to some new and better software. Nowadays, however, beta testing has gotten out of hand. As you read in Chapter 3, a staggering proportion of software firms actually ship software that has undergone no formal testing at all save for the beta test process. Further, there are huge areas of software features that may be very important but get almost no testing at all in the beta process, as they only happen occasionally—year-end closings on accounting packages, restoring files from tape with a backup program incorporated into an operating system, things like that. It's entirely possible that someone working with a beta for a few months might never need to do that year-end closing or file restoration from tape. The feedback that software vendors get from their beta testers is useful, but I don't think that's the main reason vendors give away beta copies of the software. My feeling is that the most important part of the beta testing process is marketing. By allowing users into a seemingly private club, the software vendor gets to make the user feel special, privy to some cool upcoming software. That user will then proselytize others about the software, or at least so the marketing folks hope. Further, the user often gets to communicate via e-mail with developers inside the software company; admitting him into the "inner circle" is another way to make the user feel that he has a "stake" in this software, may even be able to say ''I found bug X in package Y and they fixed it"—he changed the course of history in a small way. I believe that Microsoft's strategic placement of betas for Windows 3.0 with IS managers for major corporations had a lot to do with the acceptance of Windows 3.0 in the marketplace once the shrink-wrap product shipped. Is beta testing really about marketing and not about testing? It seems so. At an NT Magazine Professionals' Conference in the summer of 1996, Frank Artale of Microsoft claimed that over 90 percent

Page 192

of the bug reports for the beta version of NT 4.0 came from internal Microsoft users rather than external (unpaid) bug testers. Why, then, continue to distribute betas if most bugs that are found are found by internal testers? Clearly vendors don't want feedback about betas from the press, as Microsoft and most other firms try very hard to keep journalists from writing negative things about betas; it's considered unfair to beat up on an unfinished product (see Ed Foster's earlier comments). Unfortunately, there's something of a vicious circle that occurs: first a vendor releases a beta, then a journalist finds a problem but doesn't write it up because the product's a beta, then the final version appears with the bug still present, then the journalist complains about it in print, but by then it's too late. The vendor can then be magnanimous and admit to the bug, saying, "That's why we're hard at work on the next version—and would you like the beta of that software? Just remember not to write anything negative, or we may deny you future access to betas... " Okay, what can you do about this? When vendors start building new versions of the software you use—and you can be pretty sure they're doing that right now—get on the list to receive the beta. You usually apply to be on the beta testing "team" via the vendor's Web site, or just call the vendor up and ask to talk to the product manager of the product. When you get the beta, install it and use it and use it and use it. When you find a bug, there's usually a way to report it over a private Web site or via e-mail to the vendor or the like; it's a little time invested, but write up the bug and report it. And when a newer beta appears—there are usually a few versions released in a beta testing process—re-test the bug and if it's still there, re-report it and mention that you've reported this already. Many vendors host online discussion groups about their beta software where beta users can exchange experiences. They do this because it saves having to answer the same question over and over and over again. Use this to your advantage. Post messages advocating quality

Page 193

and less features. Advocate that the vendor not release this code until the bugs are fixed. As always, be polite but firm. Stress that quality in software is a modern requirement in today's world, and that it can be achieved within the vendor's time frame at the sacrifice of a few features. I don't want to leave you with a false impression, so let me stress that testing beta software takes time—a few hours each week. But being involved with a piece of software's beta process is the single most direct and effective way you can encourage quality in a particular piece of software. You as a single individual can probably never have as much influence on a product as you can during the beta process. Don't Upgrade Automatically, Make The Business Argument First Nowadays, most shrink-wrap software vendors release a new version of their products about every eighteen to twenty-four months. In turn, many firms automatically buy the upgrade and put it on their machines. As in so many other ways, here the software industry is different from almost every other industry. When cars, television sets, or house construction techniques change, we don't run right out and get a new car, TV, or house. Once in a while, a new version of something will make so much sense that most people go get it, but in general we're not hypnotized by upgrade hysteria. Sure, it was nice when air bags and anti-lock brakes appeared in cars, but car dealerships weren't exactly stampeded by frenzied buyers seeking those two features. In contrast, we allow the software industry to set our software purchase timetable. A new version of BugWord comes out in September and the next thing you know, hundreds of companies—not all, but about half—will quickly upgrade to the new BugWord. Why do many firms slavishly do this? Partly out of habit, although the habit was formed for good reasons; let's see why.

Page 194

Business and government agencies started buying PCs and PC software in earnest in the early to mid-'80s. In those days, there was usually some very compelling reasons to have the latest version of software. Each new version of software usually brought with it some ''gotta have it" feature. In the '80s, most PC software was built for the DOS operating system. By the late '80s, software vendors had squeezed about all the juice they could out of DOS, and the DOS software market stabilized. New versions of popular DOS-based programs like WordPerfect and 1-2-3 weren't immediately accepted by the market; this matured DOS software market started to look more like other markets, where new versions are not immediately snapped up. Even new versions of DOS itself didn't always sell— DOS 4.0 was sufficiently weak in advantages that most firms stayed with DOS 3.3, not upgrading until Microsoft released a significant improvement in DOS 5.0. In the early '90s, however, DOS was replaced by Windows 3.0, released in May 1990, and 3.1, released in April 1992. Moving from DOS to Windows was expensive, as Windows required faster computers and more memory than DOS; the hidden cost of Windows was that a firm moving to Windows would almost certainly have to replace all of its computers with newer models. But Windows offered compelling technological improvements: its graphical user interface made it easier to use, its multitasking capability made it possible to run more than one program at a time, and its ability to run programs that can use more memory allowed users to build larger documents and spreadsheets. An operating system is no good without applications, however. Windows presented new opportunities for software vendors, and so those developers raced to be the first to develop a "killer app" for Windows 3.0 and 3.1, and many good applications arrived for Windows. The upgrades from DOS versions of programs to the Windows versions were, again, compelling. For example, take the early '90s Windows-based word processors. They made mixing graphics and

Page 195

text simple, allowed easy use of multiple typefaces, and greatly eased the task of inserting tabular data in a document—all features that we take for granted now but that were breakthroughs in 1991. The Windows software market threatened to mature as the DOS software market did, but later on in the decade, Microsoft offered a major upgrade to Windows called Windows 95. 95 offered a few new features, but its most significant was the fact that it was largely built as 32-bit software rather than 16-bit. Windows 3 is 16-bit software, which means that Windows 3 programs can only manipulate sixteen bits at a time. In contrast, 32-bit software like Windows 95 can, as the name suggests, manipulate thirty-two bits in one operation. This 16-versus-32 difference may seem unimportant, but it's not. Having a 32-bit operating system platform like Windows 95 allows software developers to build more powerful software, and in fact developers have created some pretty cool programs for Windows 95. How did this affect upgrades? Again, if you'd upgraded your operating system to Windows 95, then there were some real benefits to be had from upgrading your applications to 32-bit applications that could take advantage of Windows 95's 32-bit platform. But not everyone has jumped on the 32-bit bandwagon. Moving from DOS to Windows offered a lot of incentive to a crowd heartily weary of DOS's limitations. But the Windows 3.1-to-Windows 95 transition just didn't—and doesn't—offer as much "bang for the buck." Yes, Windows 95's 32-bit nature is desirable. But, as mentioned before, upgrading software usually requires more powerful hardware, some user training, and the time required to put the new software onto employee's machines. Writing in the 18 August 1997 issue of Computerworld, columnist Frank Hayes reported that in 1995, 80 percent of firms said they'd probably use Windows 95, but by 1997, only 13 percent were actually using it. Of course, those who did switch to Windows 95 had a strong reason to upgrade their applications, and most people chose Microsoft's Office 95.

Page 196

But now examine the upgrade from Office 95 to Office 97. Both are collections of 32-bit software, both run on Windows 95 or Windows NT. But Office 97 does very little that Office 95 didn't do, short of a new scheduler/mail program (Outlook), some Web authoring tools, a few ease-of-use additions, and a general look that kind of ties all of the Office programs (Word, Excel, PowerPoint, Access) together. There's just not much in the way of compelling reasons to upgrade. So why upgrade, then? Why not stay with Office 95? Many IS managers I speak with admit to feeling uncomfortable with not using the latest version of whatever comes out of Microsoft, Lotus, Corel, or whomever. They cite several reasons. • Vendors don't support earlier versions. Software vendors are notorious for refusing to support a product if it's more than about three or four years old. This is unbelievable but true. Can you imagine taking your 1992 Ford Taurus into a Ford dealership to get some work done on it, only to be told that "Ford doesn't support any models before the 1993 product line?" • Users expect the latest stuff because they have it at home. If a user buys a computer, she's likely to get the latest version of Windows on it, as well as the latest version of either the Microsoft, Lotus, or Corel software suites. So, if she's using Word 97 at home but Word 95 at the office, she's likely to ask why the company is using "old technology." • The new machines coming in have it. Most firms have to buy computers every year, either to replace outdated models or to accommodate increases in staff. As with home computers, these new machines come with the "latest and greatest" software. One industry analyst told me that she believed most of Microsoft's sales of Windows 98 were essentially "compulsory" sales, as you get an operating system—Windows 98, in most cases—on any new computer that you buy, whether you like it or not.

Page 197

Clearly, the mere fact that Microsoft or Corel or Autodesk has created a new version of one of its products is not sufficient reason to upgrade. Software products are like other technological products in that they eventually mature; and, as I've already said, compare Office 95 to Office 97 and you'll probably agree that Office and products like it are mature. Until some strongly new and compelling underlying technology appears—a 64-bit operating system, perhaps, or an operating system that does an excellent job of voice recognition—it's hard to imagine much more in the way of "gotta have it" features in the next round of Windows software. Upgrading to a new version of software is essentially an investment, like deciding to upgrade your firm's motor pool or expand a factory. Your firm's accountants would scream bloody murder if someone decided to build a new factory without first doing some kind of financial analysis that forecasted in a believable way that there would be an expected return from the proposed investment. But we never do that with software, probably because years ago it was a no-brainer; new software was in general a definite plus. Before buying new software, think about trying to see if it will allow your workers to get their work done more quickly, then compute what those time savings mean to your bottom line; from there you can decide whether or not the cost of the software upgrade is justified by the savings. If it isn't, don't do it. But what about the three objections mentioned earlier? Let's look at them. First is the "lack of support" issue. If Microsoft or Corel or Lotus or whomever says it's no longer going to support the product, there are many firms that will, and they'll often do a better job. Old software is well understood, and many firms make their living selling databases of known problems and solutions pertinent to particular releases of software; you don't need the original vendor's support. And if users complain that they want to use the latest software, tell them that it just wasn't justifiable, that the firm would have been wasting

Page 198

money to buy it. Help free people from the "I must have the latest software" fixation. When new machines come in with the newer software, remove the software and install the earlier version, the company standard. You don't even have to worry about being in violation of your software license, as most of the ones that I've looked at allow you to install the software "or an earlier version" on a machine. In the 1980s, IBM and Microsoft came to expect that releasing a new version of DOS meant a guaranteed pile of money. So they got lazy and shipped DOS 4.0, expecting consumers to be good little robots and buy it. But consumers looked at it and said, "No thanks." The result? The developers went back to the drawing board and came out with DOS 5.0, an excellent value for the money. Don't misunderstand me: Microsoft, IBM, and other software vendors aren't evil villains seeking only to separate us from our money. But like most of us, they can get complacent. Make them earn their money: don't upgrade to a new version of software unless you can make a dollars-and-cents argument justifying it—even if the only person you must justify it to is yourself. And if you decide not to upgrade, rest assured you won't be alone. I know of a number of quite successful firms still using DOS programs, and many, many firms who are still using Windows 3.1 and Office 4.2, "ancient" 1992 software, without any adverse affect on their bottom lines at all. My attorney uses Word Perfect version 4.2 and it hasn't seemed to harm his business. Support "Sunshine" Software Laws You're using a piece of software and it does something strange, perhaps loses some of your data. You spend a few hours trying to figure out what happened and to reconstruct your data. Once you have some idea of what happened, you call the software vendor. You might even have to pay money to call the vendor's technical support line— unbelievable, you might have to pay the vendor company for the privilege of telling it that there's a defect in its product! Once you

Page 199

get through to a person and report the bug, you're told that the software vendor already knows about the bug. In fact, virtually all software is shipped with hundreds of known bugs. Some sources claim that Windows 3.1 shipped with 5000 known bugs. 12 Bugs wasted 65 million hours of user time—that's how long people waited on hold on software support lines in 1996.13 That's time that need not have been wasted. Why not require software vendors to post the complete list of known bugs on their Web sites when they ship the software, and to update the list regularly? It's not like this is an undue burden on the vendors, as they have extensive bug-tracking databases that they use for their own internal development process. And sellers of other products are required to do the same thing; for example, you can go to a car dealership and ask to see all the technical service bulletins on a particular make and model year of car. Airlines are required to report how often their flights leave late, and you can read that information on the Federal Aviation Administration's Web site. Additionally, make the vendors also post their return rate—what percentage of people returned the software because it was no good? "We couldn't do that," one software executive told me. "Our competitors would use that information against us." Gosh, what a shame, fellas. Here's a thought, then: don't ship it till it's ready. Further, that software firm could use its competition's bug list in the same way, right? But then what keeps a firm from deliberately underreporting its bugs? I can think of several mechanisms to reduce that possibility. First, never underestimate the power of disgruntled ex-employees. The entire development staff in a software firm has access to the internal bug database. It's the simplest thing in the world for one of BugSoft's programmers to see that the internal bug list at BugSoft lists 2000 known problems in BugWord, but the Web page only lists 117. Just one ex-employee could rat on BugSoft, leading to penalties of some sort—deliberate deception on the bug list would essentially be

Page 200

fraud. The stoolie wouldn't even have to be identified; after all, BSA and SPA don't tell firms suspected of software piracy the name of the person who reported them. Sauce for the goose and all that. Second, there are many independent sources of information about software defects, like BugNet or Woody's Office Window (both of which you'll meet later in this chapter). If independent bug lists were radically different than the official company posted list, there'd be cause for an investigation. Third, remember that there is a lot of data published by private firms that must be independently verified, and we've got extremely effective nongovernmental organizations that do that—namely, accounting firms. Publicly held companies issue annual reports that describe the health of the company. This information must be accurate or millions of investors could suffer, so annual reports are audited by independent accounting firms. Things like this go on in many industries. In the magazine industry, advertisers are charged for page space based on the number of subscribers to a magazine, so if the magazine's publisher lies about the number of subscribers, the advertisers are being overcharged. That's why magazines are required to regularly disclose their numbers of subscribers and to open their books to auditing firms. Authors are commonly paid royalties based on the number of books sold, but publishing houses are big companies and authors are often private individuals—what keeps the publishers from just under-reporting a book's sales, allowing it to cheat an author? Again, there are firms that audit publishers. The normal original reaction to the idea that outside people could "invade" a private software firm and poke through its bug database sounds like something un-American, but it's not: there are just some things that must be externally verified, and if that involves a bit of intrusion into software vendors' lives, it's not all that bad if the end result is a better market for software. Remember this quote? "Just as a company whether they're large or small has to spend time determining whether they're in compliance with state corporation laws, tax

Page 201

laws, unemployment issues, so too do they have to realize that there are legal requirements associated with the use of software.'' That was Robert Holleyman of the Business Software Alliance explaining that yes, the notion that the BSA could come knocking at your door for a surprise software audit is a pain, but that it's necessary. Given the vendors' reliance on surprise audits of user software licenses, I'm certain they'd have no objection to having the veracity of their bug lists audited in the same way, right? And that even suggests a structure for fining a software company that deliberately withholds information—let's say $100,000 for each underreported bug, just like the $100,000 fine for each stolen program? Hey, it's a start.... Currently, neither state legislatures nor Congress are considering full disclosure bug laws. Suggest this simple, commonsense remedy to your representatives at the state and federal level. In particular, advocate laws that do these things: • Require vendors to make all known bugs public, preferably on their Web sites. • Require vendors to make the terms of their software licenses public. • Require dealers of software to make the terms of software licenses available for customer inspection before purchase of the product. • Require software vendors to report, by application and version, the percentage of sales returned. Certainly no one likes to advertise their failures, but this is useful information to consumers. Airlines aren't happy about having to report the percentages of their flights that aren't on time, but they do it, and the information has benefited consumers and encouraged airlines to improve their on-time records. • Require software vendors to support older software releases for ten years. Try to get a shrink-wrap vendor—any vendor—to support a version it sold (and no doubt marketed at the time as

Page 202

the single greatest piece of software ever made); chances are you won't have any luck. In contrast, Honda dealers would have no objection to supporting my old 1984 Honda Civic, if I still owned it. Of course, if Honda refused to service vehicles more than five years old, I suppose I'd be more likely to "upgrade" my vehicle. But you can't get most software vendors to support their old software for love or money. Can Lawsuits Fix Software? Many purveyors of shoddy and/or dangerous products have been forced to mend their ways not through government intervention but by tort law—civil lawsuits brought against those purveyors by dissatisfied or injured customers. Can something like this raise the perception of the importance of quality in the software world? I asked Cem Kaner. The short answer is that lawsuits probably won't be of much help, but there are possibilities. Note that all of the following analysis is my own understanding of what Cem has said and written, and should not be taken as legal advice, nor of any indication of Cem's competence or lack thereof—any law incorrectly stated here is my misunderstanding, not his error. There are, according to Cem, seven approaches that could be taken in suing a software company: suit could be brought on the basis of an intentional tort, negligence, as a breach of contract, through misrepresentation of the product, under consumer protection laws, as a product liability suit, and for malpractice. A tort is "intentional unlawful interference with, or harm to, a person or that person's property, reputation, privacy, or business relations." Years ago, a firm named Vault sold a copy protection system used by many major shrinkwrap vendors. Vault said that it was considering a version of this software that, if it detected that you were using an illegal copy of some shrink-wrap software, would erase part or all of your hard disk. Had Vault actually done this, deliberately

Page 203

damaging a customer's data, the company probably could have been sued under tort law. Most software isn't deliberately destructive, however; it's just poorly built. Firms who poorly build software that damages data are more likely to be sued for negligence. Products must not create an "unreasonable" risk of injury or property damage. But what's reasonable? A court might well look at the quality of software in general and decide that buggy software is perfectly normal and something of an industry standard. The case described in Chapter 2, in which GM knew full well that its fuel injector program had a bug but wouldn't give a fixed version to a customer unless the customer knew to ask for it, was probably negligence. What about breach of contract? Certainly a firm could be sued if its product doesn't do what the company said it would do. But it's likely that all you'd get back would be the purchase price of the software. Related to that is misrepresentation, whether innocent or fraudulent. The only case related to misrepresentation that's gone anywhere was Ritchie Enterprises v. Honeywell Bull Inc. (1990), where a technical support person for a software firm was instructed to lie to a customer—"Sure, that feature works, just keep trying"—rather than admit that the feature didn't work. The court didn't like that, but that's a pretty heinous circumstance, one that (I hope) doesn't happen too often. Consumer protection laws could potentially be one avenue, but there's not much in the way of laws about software companies (at least not yet), and if UCITA is implemented as it stands, there won't be anything very helpful either. Product liability and malpractice may be basis for suit if the package doesn't perform to the standard you'd expect. For example, if a decision-making program that is supposed to replace a loan officer makes a set of terrible loans, loans so bad that no human would make them, then the vendor of the software might possibly be sued for one of those things. But the bottom line is that there's really not much in the way of help that the courts offer.

Page 204

I asked Cem, ''Suppose I spend days creating a document with BugWord and it crashes, destroying the document. Can't I get relief for that?" He said no. "If BugWord crashes your entire hard disk, then there might be the chance for negligence. But if all BugWord does is destroy its own files, then all that's been lost is your time, and courts aren't very good about awarding people damages on the basis of lost time." He explained it like this in an e-mail to me: I don't have a good theory for [how you recover damages for] the loss of your personal time. You can sometimes sue for the loss of an employee's time, because you paid them money so the lost time is an expense to you, not just your time. The law gets weird about stolen time. [Software firms] certainly do claim that it's your job to save early and often. In fact, they ... were able to slip this into Article 2B. In defining damages, 2B says that you (the customer) have a duty to mitigate (minimize, after a breach of contract or a tort) your damages, and then they go on to say that included in this duty is the duty to back up your software on a regular basis, just in case their garbage trashes your system. At a recent meeting of the American Bar Association, I went to a session on Law Practice Management.... In this room, half the people admitted that they didn't regularly back up their hard drive. It steams me, because the UCC is supposed to be about reflecting actual commercial practice, not about enforcing one side's fantasies about how the other side should behave. But the issue of your lost time is independent of this. I won't repeat the rationalizations. I'll just say that a plaintiff's own time is rarely considered an asset. Therefore, if I have a genuine failure and plan to seek recovery, I will probably seriously consider retaining a consultant to recover my system for me. After all, I don't have the time for this. That

Page 205 consultant's bill, I will forward to the publisher; whether I'll collect successfully is a different question.

Again, this is an extremely shortened version of a very complex issue; to learn more, I encourage you to visit Cem's Web site at www.kaner.com. Write NCCUSL About UCITA While on the topic of the law, remember that the law could get a lot less "user friendly" if the current modifications to the Uniform Commercial Code are approved at the NCCUSL meeting in July 1999. The UCC drafting process is an extremely open one, and in fact you can attend meetings of the drafting committee. Alternatively, you can address comments to: Uniform Law Commissioners 676 North St. Clair Suite 1700 Chicago, IL 60611 Or you can e-mail the main drafter of UCITA, Professor Ray Nimmer, at the University of Houston School of Law at [email protected]. But what would you say, and how would you say it? Review Chapter 4 about the particularly scary parts of UCITA, or just read it yourself; NCCUSL keeps the latest drafts on its Web site at http://www.law.upenn.edu/bll/ulc/ulc.htm. There are also many links and information about UCITA at http://www.2bguide.com. But basically, consider objecting to the following points of the proposed law: • Contracts of adhesion. Software licenses are contracts of adhesion, but UCITA makes them legal and enforceable. We

Page 206

consumers do not get to negotiate software license agreements; they should not be treated in the law as if they were contracts freely entered into between two equal parties, as UCITA suggests. We don't have a choice about whether or not to buy word processing, spreadsheet, database, e-mail, and Web browser packages; it would be impossible to carry on most modern business and commercial activities without them. • Conspicuousness. The terms of most software licenses are both silly and a secret before you buy the software. It's just not reasonable to suggest that the burden is on the buyer to box up the software and drive back to the store to return a package when her objection is to terms of the license that could easily be placed on the package's box or prominently displayed in the store. Used car dealers must put "this car is sold as is" in big letters on a car; why shouldn't software vendors do the same? • Self-help. A vendor can decide to shut your software off remotely, with just an e-mail message, leaving you high and dry. • Click-wrap licensing. Under UCITA, a vendor can present the software license in a window during the installation program for that software with a big button at the bottom of the window labeled "I accept these terms." Virtually no one will read the license: no one does now. I wonder how many of the NCCUSL commissioners—all of whom are lawyers and I'd wager all use software—have read the licenses on the software they use? If they don't do it, why presume we do? • Minimum standards of quality. Under this law, there is no requirement for software vendors to make the slightest effort to debug their products—none whatsoever. Further, they don't even have to bother scanning their products for viruses before selling them, assuming you buy the software over the Internet. You buy a piece of software over the Web, install it on your computer, and a virus in the software erases your hard disk—but you can't sue the software vendor.

Page 207

• Potential to harm the country. Making the U.S. a safe haven for buggy software, which UCITA will do, will result in even lower-quality American software, leading to dissatisfaction among consumers in this country and in others. Software firms outside of the country won't find laws protecting low-quality software in their countries, forcing them to produce good stuff. Eventually that stuff will make it into U.S. marketing channels, and then it's good night U.S. software industry. I know I sound like a broken record, but be polite in the letter. Professor Nimmer is a smart guy and he writes pretty clear stuff. He doesn't need to read your letter or this book, so be nice! Consider attending a drafting committee meeting; there are about six to eight a year held at different parts of the country. You can find out where these meetings are by looking at http://www.softwareindustry.org /issues/guide; that Web site also provides an easy place to leave comments on UCITA that will be reviewed by Professor Nimmer. The whole UCITA drafting process is a model of how democratic law is supposed to be built; literally anyone can come to the meetings and be heard. It is hard for many of us to believe that there is a place in America today where we can help shape the course of an important law, but there is such a place—the UCITA drafting meetings. If we lose this one because Big Software showed up and we didn't, then we've got no one to blame but ourselves. But by the time you read this, UCITA may well be on its way to state legislatures around the country. If UCITA goes to the states basically in the form that it's currently in, I encourage you, I beg you, I beseech you, help stop it. Write your state representatives and tell them that an anticonsumer bill like UCITA is of no benefit to anyone but the software companies, and those guys don't have that much money to contribute to campaigns—at least, not yet. Cem Kaner's site www.badsoftware.com includes a sample letter to send to your representatives. Contact Ralph Nader's Consumer Project on Technology at http://www.cptech.org for

Page 208

ideas about what you can do to stop this law from passing; there's lots of information and pointers to resources there. If It's Going To Be Terrible, At Least Admit It Watts Humphrey has made an interesting suggestion about shrink-wrap software quality. If software is truly to be sold without any guarantees of quality, if software vendors are going to cling to the fiction that it's impossible or impractical to ship quality software, then let's be completely open about it. Watts suggests the following: • Label software boxes to explain that quality is the normal responsibility of the suppliers of software products and services. Require that software vendors stand by their promises. • Allow any software vendors to offer software that they don't stand by, as is done today, but require them to clearly label those products "AS IS, UNSUPPORTED, AND USE AT YOUR OWN RISK." This is from an interesting and short paper that Watts has written called "Comments on Software Quality", you can find it at http://www .webcom.com/software/issues/guide/docs/whsq.html. Create Independent Auditing Groups When you buy a toaster, you can be fairly sure that it's not going to electrocute you when you first use it, because it's been tested by an independent firm called Underwriters' Laboratories. Is something like that possible with software? When interviewing Frank Ackerman of the Zero Defect Software Institute, I posed that question to him. "Is there," I asked, "a way to have a kind of 'Good Housekeeping Seal of Approval' for software?"

Page 209

He said, "Sure. Outside firms can do reliability measurements. The whole science of software reliability is mature enough to do something useful with it." I followed up by asking what that would cost a software vendor. "For a large package," he replied, "like Word, it could be a half million dollars to do a complete analysis. But Microsoft probably spends ten times that each year on Word development. If, on the other hand, the outside laboratory had inside access to Microsoft code and developers, it would be much, much cheaper." Like about $100,000? "Yes," he replied. That's a relatively small amount compared to revenues in the shrink-wrap industry. And having a piece of software certified by an outside lab mightn't be required; it could just be optional. Subscribe To Bug Reporting Services Until the war against bugs is won—heck, before the war against bugs is even started in earnest—you need a "forward scout," someone who can offer advanced warning of software pitfalls and potholes. If you use Microsoft products, I cannot recommend strongly enough that you subscribe to Microsoft's TechNet product. For $300 a year, you get a monthly set of CD-ROMs containing Microsoft's database of bugs and workarounds, the company's "knowledge base." I find that I turn to the knowledge base several times a month to solve some puzzler. If you can't afford $300 a year, then you can also search the knowledge base online at www.microsoft.com/kb. Other vendors have similar online services as well, so when you're faced with a bug, turn to the Web first. BugNet And if you're turning to the Web, why not visit a site specifically dedicated to reporting bugs? Such a site is www.bugnet.com, run by Bruce Brown. BugNet is a central clearinghouse for information about soft-

Page 210

ware bugs. Bruce didn't start out a techie, he just had what he calls an "epiphany." "It came to me in the summer of 1994. I was trying to use Corel Draw. I'd bought it because of all of the featurebased reviews in magazines that said it was great. If you looked at it through the lens of features, then it looked like the most wonderful thing since sliced bread. But if you used it as an actual tool, something that you used in your business and you relied on, you found out very quickly if you spent any time on the on-line venues—which at that time was mostly CompuServe—the screaming was so loud you didn't even need to turn your modem on! "It was astounding, the dichotomy between how the product was presented in the press and the reality of the product's performance. "Shortly thereafter, I went to a party here in Seattle with some friends who worked at Microsoft and, several beers into the party, they started referring to the then-upcoming Windows 95 as 'the mother of all bugs.' I got to thinking that the upcoming 32-bit operating systems would lead to new compatibility problems. People would have this amazing stew of software and hardware that they'd try to get to work together—so it'd be a tremendous problem. But the mainstream press's agenda is set by the advertisers, not their readers. What struck me was that there was a real—to use a venture capital phrase—'structural hole' here. Serendipity smiled and we're doing great!"14 Surf on over to www.bugnet.com, and you'll find (if you subscribe; annual subscriptions cost from $65 to $250 depending on company size) a monthly newsletter, periodic "bugnet alerts" to new and significant bugs, and a downloadable 1.5 megabyte database of bugs of all shapes and sizes. I asked Bruce why he thought we put up with buggy software. "It has to do with cultural expectations. You have certain expectations about quality hamburgers or cars—low quality just isn't acceptable. But there's a collision going on between different subcultures here. If you go to the broad-based culture of American society

Page 211

and look at people who buy toasters, people who buy refrigerators, people who buy the things that America buys— they expect it to work right out of the box. They do not expect to sacrifice their weekend trying to get the sucker to work. They pay money and they expect it to work—and if it doesn't work, they want their money back. They don't want to spend hours on hold on long distance trying to get help from the vendor. They want it to work or they want it gone. In contrast, in the PC and Mac subcultures, the assumptions are wildly different. The audience has been professionals or enthusiasts—it's either been a job or a hobby spending their weekends unsnarling their printer drivers. The early adopters of any technology are willing to cut the vendors a lot of slack. ''But as the PC is moved toward the position of an appliance, it comes into collision with a much broader sector of American society, the toaster buyers, and, again, they bring a much different set of assumptions to the table. They expect it to work. "So I don't think software's getting any worse or that compatibility is any more of a problem than it was in the past, just that it's being sold to a different segment of the population." Okay, so the average bear has higher expectations. Is he or she wrong to expect quality? "I don't think so, and I'd personally hope that what comes out of this process—and there'll be some turmoil along the way—is not the relaxing of expectations that average Americans expect in a consumer transaction, but rather a raising of the bar for the PC industry. They've got to raise the bar if they really want these computers to be 'appliances.' " So why doesn't it get better? "Understand that there's something going on here in the magazine side. I spent two or three decades in the media biz—worked for a ton of daily newspapers, was an investigative reporter for The New York Times national desk, foreign correspondent for Atlantic Monthly, worked for some illustrious publications and some less so—and it's

Page 212

my perception that the commercial press wants to have millions of readers that they can then turn around and sell to the advertisers. Advertisers pay the vast bulk of the freight. It's particularly prevalent in the PC realm, where the agenda of the vendors becomes the agenda of the publication. The agenda of the reader—stable, useful products out of the box—and the agenda of the company are at war with each other. When you have a media industry largely devoted to the needs of the vendors, the readers get kind of limited lip service or scant attention. That's why the structural hole existed for BugNet." Okay, the agendas of the vendors have set the game up— "Well, yeah, but remember that they're driven by outside things as well—shareholders, ROI [return on investment], and the like. There's a tremendous pressure to just get it out the door, to just ship it now! They've got to show growth, they're heavily leveraged, they're very vulnerable, and so they've got to get the software out the door or the company is toast! Programmers don't want to put out bad stuff, but it's not the only criterion." Do you talk to vendors about bugs? What do they say? "Some are quite unhappy about the role that BugNet plays. Others have more polished PR people who see this as more publicity—'just spell our name right,' that sort of thing. Most big software firms subscribe to BugNet, though." How do you collect data? "In one of three ways. First, if the bug is confirmed by the vendor, then we report it. Second, if it's been confirmed by sysops, webmasters, those kind of technical folks—they're very familiar with the product and indeed often know more about it than the technical support staff at the vendor—then we report it. And finally, if three users with different configurations all get bitten, then we'll include it. It's kind of a scientific method. Sadly, some vendors adopt a posture wherein they deny the bug exists until they've got a fix for it—and then they'll admit it. We saw that with US Robotics on their 28.8 modems and the 'pause' problem a couple of years back."

Page 213

What will fix software? "It seems to me that some sort of social process [is needed] whereby the culture puts pressure on software vendors to move toward quality. I think it's starting to happen now. We see so much, well, despair; the river of hurt among software buyers is immense and unending. "The very reasonable expectations of the American consumer will come if the lawmakers don't make laws that software vendors can hide behind. "The folks buying the products, whether as an aggregate or individuals, have a tremendous amount of power up until the point where they put their bucks down. But they've got to realize that they matter. Maybe this book will be the driving force; it may be the answer!" Aww, shucks... Woody's Office Watch BugNet is a good service, but often lacks a deep knowledge of a particular product; it's more of an encyclopedia of bugs than a set of fixes. That's where a service like Woody's Office Watch (WOW) comes in. Peter Duggan is something of a professional Microsoft watcher. To be exact, he's something of an Office watcher— Microsoft Office, that is. He edits WOW, a free weekly e-mail newsletter about Microsoft Office. "Woody" is Woody Leonhard, the author of a number of how-to books about computing. The newsletter has over 12,000 subscribers, many of whose e-mail addresses end with "@microsoft.com." (You can get WOW delivered to you by visiting its Web site at www.wopr.com, or you can just send e-mail to [email protected].) I spoke with Peter in the middle of the "SR-1 boggle." It seems that Microsoft released a set of patches and fixes for Office 97 called Service Release 1, or SR-1. It fixed a number of bugs, including a fairly egregious one wherein Word 97 cannot save files in Word 95 format, instead, saving in a kind of generic word processing

Page 214

format called Rich Text Format or RTF and claiming that the files were Word 95 files, not RTF files! This led to some confusing messages for Word 95 users trying to open these files, as Word 95, when presented with one of these files, asks if it should convert the file. ''Convert the file?," users wondered. "Why should it convert the file? Isn't it already in Word format?" Worse yet, the RTF format creates much bigger files, leading to situations where users saved files in RTF, and then were unable to open the files because they were so large. "We broke that story in Woody's Office Watch in the first issue of this year," Peter says. (The RTF fix is part of SR-1.) "The marketing guys actually denied that the files were RTF," Peter claims, adding, "They just read their own press releases and believe them."15 I asked him about shrink-wrap software in general. Why are there so many bugs in shrink-wrap software? "Because the commitment is to shipping dates and to marketing rather than to quality. Marketing and ship date comes first, and any quality concerns are a dead last. The programmers don't want it that way, but the marketers are just higher up in the hierarchy. I know this because we get lots of letters from programmers at Microsoft." Why isn't there a competing product that's better, then? "Because Office is just priced at a level where it's impossible to do that. It's hard to sell people on quality when it's tangible, but quality in software is more elusive. In the car business, for example, higher-quality cars like BMWs or Mercedes Benzes have a sex appeal attached." Why do we put up with bad software? "It's hard to blame the specific thing, a tendency for people to say, 'Oh, I did something wrong.' I think the average user feels that way. We have a tendency to blame ourselves rather than the software." Is quality a lost cause, then? "No, I don't think so. One of the things we're doing in the magazine is to try to tell people that when they've got a problem, they should complain and complain hard. If more people did that, things

Page 215

would be different. At the moment, however, people will put up with it, and the software companies know that they'll put up with it. Therefore, they can get away with it. There's so much software running in your system that it's often hard to be able to point a finger at a particular piece of software, so people just stay quiet. "Worse yet, Microsoft has gotten to the point where they can sell as features in new versions what are actually fixes for things from old versions. Over time, however, I think people will learn that they don't want to fixate on features, they want to fixate on stability and usability. Right now we're all to a certain extent blinded by the science, but eventually we'll sit down and realize, 'hey, we're not getting any more work done.' " It would be great if we could somehow compel vendors to stop adding features and start fixing bugs. "I've often said that I'd like to see Office 99 with no new features, but rather to just make the ones that already in there work properly. Of course, they'll never do that, because they're all fixated on what's new." How can things get better? Is regulation an answer? "It could be ... perhaps if there were consumer protection laws more oriented to computers. Existing laws were written before computers became prevalent." How could it work? "It's simply a matter of letting people complain. Provide a place to go when the vendor won't listen. If the vendors were forced to provide decent support for bad products, then the cost of providing that support would give them incentive to get it right in the first place. But they don't always even know their problem—software vendors tend to believe their own press. "It seems like things get fixed if lots and lots of people complain, or if it's a problem for the large corporate clients. Anything else gets ignored, they're not going to listen." But they listen to WOW—and if you use Office, so should you. It's a terrific service, and it's free.

Page 216

Some of this book may have been a bit depressing; it can be unpleasant to turn over rocks and expose what's underneath. But hopefully this chapter has offered a few remedies that all of us can use to help solve the problem. But what about if the problem isn't solved? What could the future hold in a world of "good enough" or, as Cem Kaner has dubbed it, "not-quite-terrible-enough" software? That's in the next chapter.

Page 217

Chapter 7 The Future

Page 219

Before we finish, let's consider where all this could lead. I think of the possible outcomes as the "good future" and the "bad future." The Good Future While most people don't think much about software or software quality, that changes on January 1, 2000. Although things don't turn out to be as dire as some predicted, the Y2K-induced collapse of a few Asian banks that were already fairly wobbly causes the Dow to fall to 7000, severely hurting many retirees and others planning on continued market growth for present or future income. Only a few large electrical utility company grids fail, but it's enough to cause 20 percent of the country to greet the new year without heat or electricity in the cold of January. Anger subsides over that as things are put to rights and the Dow returns to its 1999 levels over the course of a few months. Nevertheless, enough resentment remains that it's fairly simple for consumer groups to whip up enough popular opinion against UCITA. At its annual meetings in the year 2001, NCCUSL kills the bill for good, "driving the stake through its heart" as one consumer advocate crows. A few states start making noises about software "lemon" laws, and the software industry decides to forestall this talk by focusing on quality—after all, they've run out of ideas for new features, so there's no real loss. Software marketing campaigns hammer on the high quality of their products. Vendors publish their blissfully short lists of known defects and their license terms on their Web sites, saving users time they'd otherwise spend trying to make something work that just plain wouldn't work no matter what they did. Major releases of software

Page 220

take about five to eight years to produce. Annual upgrades appear, but they're minor, mostly bug fixes and drivers for new hardware that's appeared on the market after the previous major release. Shrink-wrap applications software is so reliable that the term "good enough" software just isn't heard, save as a snide reference to the Bad Old Days of twentieth-century software. Software continues to become essentially collections of self-contained "components" or "objects" that can be easily put together to accomplish some goal. Once built, these components are sufficiently reliable that they're standards. And, as those components are mainly all built in by American companies, U.S. firms have a head start on building large-scale, reliable, cheap applications. Firms outside the U.S. will need a very long time before they have a chance to catch up unless they purchase U.S.-made objects. The pervasiveness of intelligent devices means that virtually everything has at least a little software in it, and the vast majority of it's American. Useless features fall away as people recognize that there is an undeniable trade-off between numbers of features, overall quality, and cost. As BugSoft's chairman explains in the 2019 BugSoft Annual Report to Shareholders: "We'd just found that the cost of being absolutely sure that the 1000th feature wasn't causing problems for the other 999 features was actually higher than the revenue we realized from the small part of the market that wanted that feature. While we regret not being able to service that small market, the alternative would have been sacrificing reliability in our BugWord product, and that would place us at an unacceptable disadvantage compared to our competitors at Microsoft, Lotus, Corel, and CemSoft." In response, small software firms arise to service these niche markets, with very focused applications that zero in on particular sets of needs. As small firms are often the most innovative, this keeps a steady stream of new ideas flowing into cyberspace. The combination of good, reliable software and low prices, coupled with a generally rising level of technological prowess in devel-

Page 221

oping nations, creates a hunger for American software that propels the U.S. software's trade surplus to new heights, and America is again a creditor nation, although just barely. In 2029, you might hear someone remark that her 2017 Toyota Corolla is, despite its age, still "as reliable as Excel." The Bad Future Of course, things might not turn out so well. In another reality ... Software releases continue to accelerate, with firms announcing their intention to release a new minor version at least quarterly. In actual fact, they're really only able to manage to ship two new versions a year, but that's plenty. That pace of course leaves little time for testing and reliability, making "We'll fix it in the next version" a catchphrase associated in people's minds alongside "The check is in the mail, don't worry about it" and ''Of course I'll respect you in the morning." Each new version of software gets more bloated and contains more and more useless and unreliable features, but each new release contains at least one good idea or fixed feature, just enough value added to make buying the upgrade seem worthwhile as long as you don't notice the little "gotchas" in the license changes. Each new version's sales are assisted by a combination of massive marketing and vague threats on the software vendor's part to stop supporting the old versions pretty soon, so you'd better upgrade now, when the prices are low. Oddly enough, people don't even use many of the new features, as they've discovered that some of these new features are so poorly tested that they can end up corrupting existing data; experimentation can be risky, so the software keeps getting bigger but almost no one benefits from the larger software. Eventually, people stop seeing software as a "cutting edge" industry and more of a nuisance; inevitable things are said to be "as certain as bugs and taxes." In the fall of 2000, NCCUSL passes UCITA to the state legisla-

Page 222

tures. Consumer groups wave the ''Remember Y2K!" flag, but Americans are busy following the latest political scandals, and UCITA doesn't appear on their radar screens. Software firms lobby the states mercilessly, and forty of the fifty state legislatures pass it. By 2005, it's essentially the law of the land. Anything in the hidden-until-aftersale software license is enforceable, no matter how silly; it's a golden age for software companies. Armed with this shamefully anticonsumer law, the software industry gets more and more rabid about protecting its licenses, and people come to talk about the BSA and SIIA's software cops the way they talk about the tax man nowadays. Quality in American software products plummets, as there are no real incentives to provide it anymore. Meanwhile, software firms outside of the U.S. must still produce high-quality software, and they do. Initially, American firms shy away from using foreign software, as its packaging looks amateurish and the documentation either isn't in English or is in broken English. But eventually people overlook those quirks and come to like software that doesn't crash several times a day. The American hegemony in the software market begins to erode. There are lots of computers in cars, so better software means better cars. High-quality German and Indian automotive software becomes the world standard; soon almost every new car contains software written in one of these countries. Even "American-made" cars contain hundreds of dollars' worth of foreign-built software, with the overall result that the trade deficit worsens. As the years pass, people become more angry about software. Tempers rise to a fever pitch when, in 2007, CheckBug, BugSoft's personal tax and checking program, miscalculates taxes for 87 percent of its users, costing them over $50 billion in collective tax penalties and interest. BugSoft responds lamely with a free upgrade to the latest version of CheckBug, fueling greater outrage. A class action suit brought against BugSoft is, of course, thrown out of court on the basis of UCITA, and voters begin yelling for reform legislation. Eager to have an issue that'll keep voters from focusing on the side effects of

Page 223

the mounting trade deficit, Federal lawmakers pump out a knee-jerk response, the Software Quality Act (SQA) of 2008. Its provisions include a national Board of Software Quality Review, a government organization that must approve all new software in the same way that the Food and Drug Administration must approve all new pharmaceuticals; it now takes software vendors five years to get a product approved for sale. Another provision restricts software vendors from devoting any resources to developing new products until every possible bug is eliminated from current versions of software. It's generally agreed to be a bad provision, but intellectual property lawyers just shake their heads and muse, "Legislate in haste, repent in lawsuits." Software vendors can be sued for virtually any inconvenience their software causes a user. Lawyers rub their hands in glee, and software CEOs begin to wonder why they didn't just go to medical school like their mothers wanted. The effect on the software industry is swift and devastating. By 2010, not a single American software firm is developing new software, as they're all devoting all of their resources to removing existing bugs. A small cottage industry arises in the form of people who spend all of their time finding bugs in software so that they can then sue software firms, suits that invariably lead to small out-of-court settlements but that serve to drain software firms' already dwindling resources. Meanwhile, foreign firms continue to innovate. Most foreign software has not yet passed muster with the Board of Software Quality Review, but that doesn't matter, as the firms sell their software over the Web from servers in their own countries. By 2015, a survey shows that 53 percent of homes and businesses use this uncertified software, despite the fact that buying such software is illegal. The public doesn't care; yes, it's technically illegal, but first of all, it's a victimless crime and, more important we've all known for a decade that foreign software is cleaner than American code anyway, right? By 2017, Congress repeals the Software Quality Act of 2008, but it's too late: not a single American software company has any cash

Page 224

after nine years of legal battles, as they've spent it all responding to nuisance suits. The firms that are left have some relatively bug-free code, but they got there by doing no innovation at all in the past thirteen years and by slashing features. The products are good, but they're expensive. Cash-rich foreign vendors swoop into the American market and undercut the American firms on price, buying outright the firms they can't simply drive out of business. By 2020, 78 percent of software purchased in the U.S. is built offshore. American software constitutes a mere 5 percent of the world software market. Congress scraps development of the new F-179 fighter jet when experts testify that there's not enough high-powered software development talent in the country to build the software that this state-ofthe-art space-plane requires, and the alternative—letting a foreign power control the software of a pivotal American weapon system—is unacceptable from the point of view of national security. Which will happen—the good future or the bad future? It's up to us all. Right now, competing applications battle for market share by comparing features rather than reliability—but it doesn't have to stay that way. This could be the year that the features war ended and the bug war began. All we've got to do is to require that software vendors provide the same quality that we require of the butcher, the baker, and the automobile maker.

Page 225

Appendix: Software Self-defense

Page 227

This book has mainly concerned itself with the big picture, the software industry as a whole and what I feel needs to happen in order for quality to become a top priority in that industry. But until that day comes, we live in a world of buggy software and you've got to cope with it. This appendix aims to assist you in convincing a software vendor to give you your money's worth, and to suggest a few skills that would be worth acquiring in order to make yourself able to solve many software failures on your own. In this last part of the book, I'm going to arm you with some strategies that will maximize your chances of getting satisfaction from a software vendor. But before I do that, I'm going to have to convene a short class in software architecture. Stay with me, it'll be worth it. Don't Blame The Wrong Software, Know The Parts Most of us run programs that we didn't write—we bought them from Lotus, Oracle, Microsoft, Netscape, or some other firm, so when we come across bugs, we haven't a hope of going into the program code and fixing it. We do, however, have several possible responses after discovering a bug. One of those responses is to call the vendor and report the bug, hoping for a fix—but that often leads to the kind of frustrating conversation I have described elsewhere in this book. Before you can run a simple Windows word processor, your computer must load dozens of programs, many of which are often written by a number of vendors. This makes it easy for the word processor vendor to avoid taking the blame for problems with its product. If you understand how software works, it'll be easier to understand how it can not work. Basically, you (the user) want to use your

Page 228

computer (the hardware) to get something done. In addition to these two parts (you and the computer), there is software. Most folks don't know this, but there are actually three kinds of software in your computer. They're called application programs, operating systems, and driver programs or drivers. Again, why do you care? Because if you're calling Microsoft to complain about their word processor but the problem comes from Epson's printer driver, then Microsoft will be about as helpful as Chrysler would be if you called them to complain that the Michelin tires you put on the car don't work. And if they know you don't know the difference, then they may just start pointing fingers just to get you off the phone and push blame away from themselves, even though their applications are at fault. (Of course, sometimes it really is the drivers; I'll give you hints in the rest of the appendix about how to isolate a problem's source.) Application Programs Applications are the easiest of the trio to understand; they're why you use the computer in the first place. Applications are the programs that let you get something done, like writing a letter, doing your taxes, playing a game, or keeping the bowling team's statistics. The most popular applications are games, word processors, electronic mail programs, and Web browsers. Heart Of Code: The Operating System Applications are the only part of the computer that most of us really care about, but the computer couldn't function without the operating system. The operating system is the foundation that the application rests upon, much as a house sits upon its foundation. It's a set of programs that provide basic services to applications. Operating systems simplify the process of writing programs by freeing application programmers from having to do a lot of basic reinventing of the

Page 229

wheel. An operating system also acts as a manager for computer software, making it possible to load and run several applications all at once. Writing applications is complex, and one of the most complex parts of applications programming involves interacting with the real world. If you decided to sit down with a C compiler and build the world's greatest word processor, what are the things you'd be thinking about? Perhaps smooth integration of text and graphics? The ability to simply and easily build Web pages, or to build colorful magazine pages? Those are important, but the word processor is completely useless unless it can properly save a file and later retrieve that file from disk. In fact, nearly every single application must be able to read and write files. Nearly every program must be able to read keystrokes from a keyboard and put information on a screen, and to send information to a printer. But none of that kind of programming is easy. For example, just to send the message "Hi!" to the printer so that the line "Hi!" is printed, a program must first of all check that the system has a printer, and that the printer is attached. Then it must know what particular printing language the printer speaks, as there are at least two major printing languages that most printers employ, either Hewlett-Packard Printer Control Language or PostScript. Next, the printer's no good without paper, right? So the program must check with the printer to see if there's paper in the printer, and so on. Just thinking about the things you'd have to do just to print a line of text on a printer—much less worrying about display monitors, keyboards, mice, and disk drives—the generic phrase is peripherals—is enough to make a prospective applications developer decide to go into another line of work. But consider: if a computer has ten programs on it, each one of those programs must print, display, listen to the keyboard and mouse, and so on. Wouldn't it be incredibly wasteful to make the developers of each one of those applications reinvent the same wheels? Of course it would, which brings me back to one of the reasons that operating systems are essential. Among other things, and

Page 230

operating system includes already-written, "pre-baked" programs to do the computing scutwork of printing, displaying, and the like. These pre-written programs act as a sort of toolkit that applications designers can build upon. Thus, if you were to sit down to design the world's greatest word processor, you'd have plenty of work ahead of you, but at least you wouldn't have to sweat the basics. In addition to including routines (routines is another bit of programmer-speak that just means "small programs that do a particular function"—like printing or saving a file to disk) to handle interaction with pieces of hardware outside the computer, such as printers, displays, mice, keyboards, and the like, the operating system also acts as a kind of traffic cop, managing how different applications share some important hardware inside the computer. Modern operating systems allow you to run more than one application at a time, a process called multitasking. On the face of it, multitasking seems like a bit of magic. After all, your computer probably only has one processor chip or central processing unit (CPU), the "big brain" of the outfit. A CPU can really only do one thing at a time, so how can one CPU run multiple programs at the same time? With a little sleight of hand—the operating system essentially "juggles" all of the applications that you're running at any given moment. The operating system must then decide how much of the CPU's attention to give to each program—should the word processor get more time than the Web browser when the Web browser is just quietly downloading some files, and the user is busily banging away at the keyboard entering text into the word processor? Apportioning out the CPU's attention is an incredibly important task that operating systems provide... and when that apportionment goes wrong, it can sometimes go horribly wrong. Ever pressed a key on your computer, only to be ignored? Clicked the mouse and gotten no effect? Perhaps you even got up and folded the clothes in the dryer, thinking that the computer would have worked the problem out by the time you returned ... but when you

Page 231

got back to the PC, it still wasn't responding to you? The only answer is often to just shut the thing off and then turn it back on again, which certainly "unlocks" the computer but may well have cost you some data—any word processing files or spreadsheets that you hadn't saved before the system locked up. What causes this kind of lockup is often a failure in the part of the operating system that tells the CPU which programs to pay attention to. Every computer has a small program whose job it is to just listen at the keyboard, waiting for you to press a key, and then to take that keystroke and carry out whatever command you intended with that keystroke; there's a similar program to detect and act upon mouse clicks. But suppose a bug in the operating system causes the operating system to essentially tell the CPU, "Don't spend any time on those keyboard and mouse programs, they're not very important; instead, why not do some high-priority meditation on something like, oh, watching the clock?" The computer is then so fascinated with watching the milliseconds tick by on the clock that it ignores your efforts to communicate with it. The point is this: failures in how the operating system allocate the CPU's attention can cause software failures, and those failures don't necessarily have anything to do with whatever application program you're running at the time. What we see as users, however, is that one minute we're running Word and the next minute we're locked up. Did Word cause the lockup? Perhaps. But perhaps the fault in that case lies not with Word for Windows, but in Windows itself. Another function of the operating system's multitasking management is to allocate memory (also known as RAM, short for the not-very-helpful phrase random access memory; don't try to make sense of what the words random, access, and memory mean when strung together like this, as there isn't much sense to it, trust me) among the many applications being multitasked. Memory is a much-sought-after resource for programs, meaning that most applications are pretty RAM hungry—there's never enough to go around. Consequently, if you're running a browser, a word processor, an e-mail package, and

Page 232

perhaps a game, then each of these applications have been given some amount of memory. Think of areas of computer memory as being like plots of land, and each program wants to build its own grandiose multi-acre mansion. There's only so much area to give away, however, and so the zoning board—that's the operating system— tells each application that it's terribly sorry, but that application will just have to make do with smaller amounts: perhaps the e-mail program gets no more than a quarter of an acre, but the word processor may get an entire acre. The operating system draws ''property lines" in the memory, allocates a "lot" to each application, and tells the applications to get to work. What could go wrong here? Lots. (No pun intended, at least none I'm willing to admit.) First, what if an application just plain decides to ignore the operating system? What if the e-mail package says to itself, "I've been memory-oppressed for too long, so the heck with that tyrannical operating system, I'm goin' for the gold," and grabs an entire acre? Well, that in itself is troubling—we certainly want an orderly computer, and these small revolts don't help along those lines—but what's more troubling is when you consider the side effect. If the email package has exceeded its quarter-acre, it's almost certainly started building on someone else's lot. Getting away from the land metaphor and getting more computer-specific, here's what could happen. You load a word processor, your e-mail package, and a web browser. The operating system figures out how much memory each one needs, and allocates that memory to them. Memory's not allocated in acres, of course, but instead in units of bytes (eight bits)—about the amount of space needed in a computer to store one text character. One byte's not very much space, and in fact memory is usually referred to in kilobytes (1024 bytes), megabytes (a little over a million bytes), or gigabytes (a little over a billion bytes). PC programs commonly require anywhere from a kilobyte or two on up to a dozen of so megabytes for the real RAM hogs.

Page 233

So suppose the word processor has eight megabytes at its disposal, the e-mail package one megabyte, and the Web browser six megabytes. The e-mail package, sandwiched in between the word processor and the Web browser, starts out working just fine in its one-megabyte space, as the e-mail package is in general well written. But you finish reading your mail and decide to do something unusual, like change your e-mail password. Now, there's probably a small set of separate routines inside the e-mail package that control password changes. Those routines probably didn't get tested as thoroughly as the more frequently used functions, or perhaps never tested at all—15 percent of software firms ship out software without any formal testing at all, as we've already seen. Then suppose there's a bug in one of the password-changing routines that says, ''Here, write some data in the second megabyte of memory that the e-mail package owns." The second megabyte? The e-mail package only has one megabyte—but for whatever reason, the password changing routine doesn't know that, and so starts writing data outside of the email program's allotted space. This would be like hiring a contractor to put a patio in your yard and giving him directions to "walk 100 feet north of my front door and start pouring concrete"—when your property line stops 50 feet north. If the contractor weren't too bright, your neighbor might end up with a patio in her living room, which might not be the exact architectural statement she'd prefer. In the case of the e-mail package, it would probably end up writing this data over the space occupied by the Web browser, probably causing the Web browser to either behave strangely or crash altogether. So one application overwriting another application's area—scribbling and clobbering are the words programmers use for such an overwrite—can damage another application, a troubling idea. It could be that while the e-mail program actually had the bug, you'd only see bad behavior from the Web browser, causing you to conclude that the browser was buggy, not the e-mail program!

Page 234

Why did the operating system allow the e-mail package to scribble all over browser's space in the first place? Well, a good operating system wouldn't, but versions of the Macintosh and Windows operating systems have allowed this to happen, and both still do to an extent. Under Windows 3.1, it was childishly simple for one application to ignore the instructions of the operating system and scribble on another application's memory area. Windows 95 is better at enforcing memory "fences," but is still fairly easy to bypass. Microsoft markets its NT product as being "industrial strength" partially because NT is much better than Windows 95 at keeping applications from cobbering each other's memory areas. Ever run a program in Windows and been told that the program has created a ''GP Fault" or "General Protection Fault?" That's Windows-ese for "I caught one program trying to scribble in another program's area," and while error messages are never happy events, this one is in some ways positive, as it says that (1) the operating system successfully detected one program trying to do something undesirable and (2) it stopped the program before it did it. That's certainly better than just having the computer freeze up randomly! They Don't Call Them Drivers Just Because They Drive You Crazy The third part of the computer software trio is device drivers. Drivers help make operating systems hardware independent and more flexible; to see what that means, let's return to printers. There are hundreds of laser, ink jet, dot matrix, and daisy wheel printers on the market. Any programmer wants her application to support as many of these printers as possible. But every printer has its own distinctive language. The result is not a happy one: the programmer has to write a small program for each printer on the PC market and include it in her word processing program. That way, whether a customer has an Epson Stylus or an HP LaserJet, that customer will be able to use the word processing program.

Page 235

Sounds like a reasonable enough answer, but it isn't. First of all, consider the effect of all of those small programs on the word processor's size overall. Figure each printer needs a program that's, say, five kilobytes, or 5K, in size. Figure also that there are at any moment in time about 200 printers that are common enough on the market that any smart software entrepreneur has no choice but to support them. That's 1000K, or one megabyte. One megabyte may well be about 20 percent of the total size of the word processing program—that's a lot just to support printers. Then consider that the programmer will also have to write small programs to support particular mice, video display hardware, possibly scanners—and the list goes on and on. The net effect would probably be to double the size of the program with all of these individually small programs that support hardware, and the silliest part is that most of the code would be unused—what good is it wasting a megabyte of your memory on printer support programs when you never use more than 5K of that? Clearly it makes no sense, so these small programs that support printers, mice, display units, or whatever kind of hardware are shipped by the programmer as separate modules and only the relevant programs are installed on the computer. These programs are called drivers. The RAM draw of drivers is reduced by their modular nature—by the fact that you get to pick and choose which ones you load, saving space. Actually, it would be nice if the rest of the application worked this way: if you knew that you'd never use the revision tracking or equation editor, your word processor would never load it, with the desirable results that (1) the program takes up less memory and (2) less code loaded means less code to fail, leading to a more reliable system. In any case, this whole driver business sounds like it's something that applications programmers shouldn't be messing with; this kind of "control the specific hardware" housekeeping sounds like the operating system's job, and in fact it is. Now, if you ever used a word

Page 236

processor under DOS, like Word Perfect 5.1, then you had to load printer drivers—but they were only drivers that worked for Word Perfect. If you ran a different program, like the 1-2-3 spreadsheet, then it, too, had its own drivers. Why did Word Perfect and 1-2-3 need their own drivers? Because DOS for the PC wasn't really an operating system in the complete sense. In contrast, you can run any number of applications under a newer operating system like Windows or the Macintosh operating system and all of those applications will share a single driver. Finally, drivers make operating systems flexible. If Microsoft ships a version of Windows in November 1998 and Hewlett-Packard comes out with a new printer in December 1998, then Microsoft doesn't have to issue a whole new version of Windows just to support the new HP printer; all it's got to do is to get a driver for the printer and distribute it to anyone who needs it. Or should Hewlett-Packard do it? That's a perennial battle in the driver world between operating system vendors and hardware vendors—the hardware guys say it's the job of the operating system guys to write the driver for the new hardware, and the operating system guys say the reverse. Where do drivers fit into software reliability... or unreliability? Quite snugly, unfortunately. In case it's not yet clear, drivers are essential pieces of software. A buggy printer driver is a piece of software that could crash your system every single time you try to print, taking all your work with it as it crashes. A suddenly misbehaving keyboard or mouse driver might make you unable to control the computer, and a bad video driver could make the screen unreadable. Despite drivers' importance, they're not always well tested. Generally the person who writes the drivers for a piece of hardware is an employee of the company that made the hardware. That driver writer is, then, a software professional (a programmer) working in a company of hardware professionals (engineers). Programmers and engineers don't always get along so well, and being the one software guy in a building full of hardware guys often isn't a fun job. Even in a

Page 237

crowd of programmers, driver writers don't get all that much respect; it's not fun, it's not glitzy. When drivers work, no one notices them. When drivers don't work, well, that's not exactly the kind of attention most programmers crave. In contrast, if the latest version of a word processor includes some cool new "wizard" routine that helps novice users create beautiful Web pages in just a couple of minutes, that's impressive—when that works, people notice, and notice in a positive way! It's a similar story in a hardware-oriented company: when the company unveils the latest video display hardware and can demonstrate more colors, more speed, and more action, it's the people who designed the electronics that get patted on the back. I see things like this at big computer trade shows all the time; after the vendor finishes demonstrating his great new faster/cheaper/better device, I'll ask, "When will it support NT?" naming the operating system that I spend a lot of time working with. The vendor sighs. "We hope to get the NT drivers out in six months," he says, and looks over my shoulder, eyeing the crowd for someone else to buttonhole. Most hardware vendors see drivers as an afterthought, a chore. While it isn't universally true, driver writers tend to be the "low people on the totem pole." I want to stress that not every hardware producer sees drivers this way, but many do. When trying to figure out why a piece of software isn't working, then, remember that there are five pieces in a computer system, and any one of them can fail. Why five? Well, as we've seen, there are the three kinds of software—applications, operating systems, and drivers; the fourth piece is the hardware, which can also fail. (Good troubleshooters prove that hardware's not causing the problem by "isolating" the hardware. In other words, if they think that the video board is what's making the PC crash, they take that video board out, replace it with a similar one, and see if the crashes still occur. You may not have extra hardware lying around to use for testing purposes, granted, but it's worth thinking about having some available, as hardware's cheap these days. You can then verify that the problem isn't your

Page 238

hardware by using the "swap till you drop" method, presuming that you're comfortable working inside a computer.) And the fifth piece? The operator; we people make mistakes when using computers as well. Strategies For Working Around Bugs That was a bit of a lengthy explanation of applications, operating systems, and drivers, but it was essential so that you can understand how to use this information to work around bugs and get better support. Thanks for staying with me this long; here's some small reward. Ideally, you and most users of computers should never have to think about bugs. In Chapter 6, we talked about how to deal with buggy software in the larger sense—how to help create that market environment where bad software's not an option. Until then, however, we live in a world of buggy software, and when a bug strikes, you've got three choices: get the vendor's help, figure out a way to work around the problem, or give up on whatever you're trying to do. Surrender is not an option, at least not without a good fight. In the remainder of the chapter, I'll outline a set of strategies you can use to try to cope with failed software. I'll present them roughly in order of complexity, but even if some of this gets a bit beyond you, understand this: even if you go pay someone to try to fix your computer problem, these are the same strategies that she'll use. Even if you don't do these things, you'll understand better what someone's charging you for. What To Do Before Calling The Vendor While jumping on the phone and yelling at the software vendor's support people may be cathartic—I know I enjoy questioning the lineage of some "support" staffs—it won't get the problem solved. Here are a few things to be sure to do before you call the software

Page 239

vendor's help line. Even better, you'll often find that in the process of collecting this information, you'll solve the problem by yourself. Get All Your Ownership Information Together and Handy. Many vendors won't talk to you unless you can prove that you're a legal, paid-up owner of a piece of software. Most software has a serial number of some kind that identifies your particular copy of the software; have that close at hand before calling. Collect Your System's Information. You can make the help desk person's job easier (and get quicker service) if you already know the make and model of your computer, how much RAM it has, what sort of video board is in it, and what operating system it's running—Windows 3.1, Windows 95, Windows 98, MacOS, whatever you've got. You should have gotten that information when you bought the computer. If you're running Windows 95 or Windows 98, you can get a lot of that information by clicking the "My Computer" icon with the right mouse button; a small menu will appear. Click the "Properties" option and you'll find out what version of Windows you're running, what kind of CPU is in your machine, and how much RAM your system has. Have all that ready beforehand, so the phone support person doesn't have a chance to put you on "ignore." (Never heard of ignore? It's a term used inside the phone support business. People outside the business call it hold.) Keep a Log of the Changes You Make to Your System and, if Possible, Undo Them, Then See if the Bug Disappears. Keep the Log Close at Hand When Calling the Vendor. Recently, I added more memory to one of my laptop computers. All of a sudden, Windows 98, the operating system that I run on that computer, started acting strangely. I'd create a file and it would lose it. I'd go to open up a document or a program and the system would crash. It was as if my system had come down with an illness of some kind.

Page 240

What was going on? Given these circumstances, it seems likely that there was some kind of connection between the new memory and my problem, and there was. The new memory was faulty, and, as Windows uses all of the memory in your system, it began using the new memory, storing important information in that memory. The faulty memory, meanwhile, would remember that data incorrectly, and when Windows asked for the data in the memory, it got damaged data. Windows generally has no way of knowing that data's been damaged, however, and so it trusts the damaged information, leading to any number of problems. Adding new hardware to your computer always creates a risk that the system will fail. Based on twenty-five years of experience in buying and installing computer hardware, I'd hazard a guess that 10 to 20 percent of new hardware is faulty in some way. My strong advice is: when you install a new piece of hardware in your system—or, as is more likely, you pay someone to install a new piece of hardware in your system—then you or the installer should run a diagnostic program of some kind to test that hardware. Usually these diagnostics come with the new hardware. But incorporating new hardware into your system can affect the system's reliability even if the hardware is solid. That's because you'll recall that your applications don't directly interact with hardware, they interact with the operating system, and even the operating system doesn't directly interact with the hardware; rather, the operating system relies upon driver programs to access hardware. What if the new drivers have a problem? It's usually possible to run a diagnostic program on a piece of new hardware and thus to have some level of confidence in the hardware—there's no easy way, in contrast, to test out a new driver except the hard way: just load it on your system and pray. In the same way, loading any new software, whether it's a new or updated application, operating system, or driver, creates a possibility of new vulnerabilities. Now, no one would suggest that all new software will make your system more wobbly, but it's important to under-

Page 241

stand that there's a reason why people say, "If it ain't broke, don't fix it." Sadly, however, just about all software's "broke," to a certain extent, so perhaps a more apt bromide is, "Better the devil you know . ." Any change in a system creates a possible fault, and you want to be able to undo that fault. That's why you should keep a log of some kind of every change you make to the system—every new piece of hardware or software. This sounds like it's some work, but it's really common sense, right? If you were fairly happy with the way your car was running and took it in to get a new set of tires and a front-end alignment, and soon thereafter started having trouble with the car, what would your first guess be about a possible cause? Always ask yourself: "What's changed since I last did this?" Granted, you probably don't keep a log of things you do to your car, but having a computer log will make life much easier when you experience computer problems, as you'll unfortunately make a lot more changes to your computer in a year than you will to your car. Buy and Learn to Use an Anti-virus Program. Whenever you get a program or data file from some source, there is a chance that the new file might carry with it a computer virus. Computer viruses are destructive programs written by computer criminals. These programs hide themselves in program or data files and then essentially use those programs to infiltrate your computer. Once inside, they can do all manner of damage to your data. Some viruses announce their presence quite loudly by erasing all of the data on your computer. Others work differently, and their effects can be more subtle, perhaps just a file or two is corrupted, or the computer just behaves oddly. For example, a couple of years ago a member of my staff was trying to install Microsoft's NT on a computer, and he was having no luck at all. He'd get partway through the installation process and the system would just die. It initially seemed odd—we'd successfully put NT on that system before—when I got the idea to scan for a virus and, sure enough, there was a virus on the disk. After removing it, the NT instal-

Page 242

lation went flawlessly. Had I called Microsoft for help before discovering the virus, it could have been embarrassing indeed! Viruses come and go all the time, so be sure also to check your antivirus vendor's Web site for updates. They usually have files that you can download so that your antivirus program is equipped to find the latest nasties. Look on the Vendor's Web Site to See if There Is a Notice About Your Bug. Many of the better-run software companies keep large databases of known bugs on their Web sites, and anyone can search these databases. Just go to the vendor's Web site and look for a link labeled "Support"; that's usually where you go to see if they have a searchable database of problems (and, one hopes, solutions). It's usually quite easy to access these databases, and most even come with help for beginners on how to search. You may find after using them for a while that you prefer Web-based databases for support. For one thing, you can access them twenty-four hours a day, seven days a week. And for another thing, it's often sadly true that the people answering the phone at the vendor's help line aren't as well informed about the product as is the database on the Web. Software Vendors Are Much More Likely to Listen if the Problem Is Repeatable. Try to outline a step-by-step set of actions that can repeatably lead to the bug. If your spreadsheet freezes up out of the blue for no apparent reason and in the process kills eight hours of your work, calling the vendor often won't help much. Granted, the spreadsheet shouldn't do that, but if you can't get it to do it again, the chances that the vendor will be able or willing to help are pretty small. If the conversation goes like this: You: I was using your spreadsheet and it locked up. Vendor: Do you have any clue why it did that? Did something change, or did you do something differently?

Page 243

You: No, I was just using it for work like I always do, and wham! It just lost all my data. At this point, you'll get one of several responses from the vendor. Response 1: Oh, I know what that one is—it's the Wednesday crash. Every fourth Wednesday, the spreadsheet crashes for no apparent reason. We're sorry about that, we've almost got it fixed, and we'll send the fix to you free when it's completed. Please tell us how many hours' work you lost due to our failed product, and your hourly rate, and we'll reimburse you ... (Okay, I admit it, I included this response for comic relief.) Response 2: I'm afraid I can't help you, sir; I just don't have any information to work from. (Useless, but at least honest.) Response 3: Tell me exactly what hardware you have in your system. (Assuming that you actually know that you've got an XB-29 video board rather than an XA-32G video board, you tell the vendor. What he's doing is comparing your hardware to a list of ''approved hardware," hardware they've tested the software on. If he finds anything of yours that isn't on the list, he can just blame you for not having the right hardware. Look back to Chapter 6 for possible response strategies.) Response 4: I really don't know, but I note that you don't have the latest version of our software. Can I sell you an upgrade? (This is merely snake oil sales disguised as technical support. This was

Page 244

also discussed in Chapter 6, but in brief, you should now ask: ''So let me get this straight—I bought a product from your company and it doesn't work and now you're going to make me give you more money, and you still aren't sure it'll work?") In contrast, suppose your answer to the "what were you doing differently" question is: You: I don't know what I'm doing differently, but I do know that if I turn on my computer and start the spreadsheet as the first program, and if I load a particular file first, and then I start working, the spreadsheet will freeze up within 20 minutes. At this point, the vendor probably still doesn't know the answer, but can now (assuming he's genuinely interested in helping you) drill down with some specific questions, possibly uncovering the source of the problem. When You Call You're ready. You place the call to the vendor's support line. And you're treated to twenty minutes of music on hold. Time to sharpen your Solitaire game ... ah, but finally you get a human. The human just wants you to prove that you're a legal owner of the software, so you give him your serial number ... and you're back on hold. You will probably talk to a human soon, so there are a couple of things to be sure to do. Keep a Log. Eventually, you get to talk to a human, assuming that having to listen to thirty minutes of Kenny G doesn't make your brain implode. You'll hear something like "Hi, how can I help you?" Rather than launching into a description of the program problem, briefly say that

Page 245

you're having a problem with product X but, just in case you're disconnected, could you get the name and direct extension of the friendly support person on the other end of the line? Keep a log of everyone that you talk to. If possible, try to stay with one person throughout the many phone calls that you may have to make in order to get satisfaction. Ask For Remedies. Make yourself a list of the things that you want to accomplish. One of the items on the list should be Get the vendor to admit the failure. The entire tenor of the conversation changes once you've done that. There may be a bit of weaseling along the way, but if you get confirmation that this is indeed a defect in the product, you can ask for a fix. Often the support person will acknowledge the bug but will say that you've got to buy an upgrade to get it fixed. Ask why. The product's defective, they admit it's defective, why not fix it? If nothing else, you may get the upgrade free (as if that's a good thing). Further Strategies If your first foray into technical support gets you nowhere, it's time to try the next level. If You Can Repeat the Bug, Can You Repeat It on Other Hardware? You've discovered that your checkbook program "forgets" checks every now and then. After some mucking around with the program, you find that it actually forgets every 256th check that you enter into your personal checkbook. But how to get the vendor to fix it? See if the bug appears on other people's computers, as well. Being able to repeat a bug helps get a vendor's attention, but being able to demonstrate that the bug will lose checking transactions on a wide variety of systems cannot help but get the vendor's attention! And, if the vendor still refuses to do anything about it, it'll be easier to get others interested in spreading the word: for instance, a

Page 246

computer magazine will be more likely to write about the bug if it can appear on a variety of hardware than if it just happens on a very narrow set of configurations. Get Escalated. People who actually know what they're talking about when it comes to computers are not only pretty scarce, they're expensive. As a result, most telephone help desks are arranged into at least two levels. All initial calls are handled by low-paid "level 1" support people; there's usually a lot of those at a given help desk, and relatively fewer "level 2" or "second-level'' support people—the level 2s are those who (with luck) really know their onions. (Given the shortage of qualified people in the computer business, even this isn't necessarily true, but at least the second-levels know more than the first-levels.) The level 1 folks have usually received minimal training and have a list of the twenty-five most commonly asked questions, the only ones that they know how to answer; I've talked to level Is who were either too dumb or too lazy to search their own company's Web database. Sound fanciful? It's not, believe me—one day you'll find yourself explaining to a support person for Acme Software exactly what Acme Software's products do. Anyway, if you ask a level 1 a question that he can't answer, he's got to decide either to "escalate" you (the industry term) up to one of the second-levels. Second-levels are busy, however, and so there's usually some pressure not to bother them with dumb user questions. In that case, all you get for your half hour's time on hold is a "Have a nice day'' and "Be sure to buy our upgrade next month, it'll probably fix it," followed by dial tone. Your quest is to be escalated rather than discarded. If it sounds like the first-level support person has about exhausted his resources, come right out and ask to be escalated to a second-level. It's sad but true that if you sound like an insider—"It sounds like we're about out of ideas here; can you escalate this to a second-level, please?"—then you get better service.

Page 247

Another, more difficult, strategy is to try to skip the level 1 altogether. I'll do that when I've got a bunch of questions about a product and am seeking answers. I just choose the most specific, geeky question I've got and ask that one first. I usually get an immediate, "Uh... can you hold," and instant escalation to a second-level. (The second-level can't always help either, but at least I've saved time. And because I have a name and extension, I've got someone to contact directly if I've got future problems.) Oh, and one more weapon to use in your arsenal here: charm. Remember they can just "accidentally" hang up whenever they feel like it. Look to Other Sources for Help. If the software vendor isn't helping much, don't give up. There are others who will willingly help people with software troubles. Communications networks like CompuServe and America OnLine have areas called forums, where people with similar interests can converse; some of those forums focus on particular software products. The Internet plays host to a vast discussion network called newsgroups, and there are literally tens of thousands of newsgroups. Many of them discuss particular computer products—what works, what doesn't, workarounds for things that don't work, and the like. No one moderates these discussions, so they're not well organized and, truthfully, there's often not much useful information ("the signal-to-noise ratio is pretty low," as a techie friend recently commented), but sometimes there's help there. Some computer magazines also host discussion systems on their Web sites where you can post a question or browse through previous questions and answers. Understand, however, if you seek help on a newsgroup, forum, or other free support service, that the people doing the helping are just volunteers. If you post a question, you might not get an answer—there's no guarantee.

Page 248

If You Can't Isolate a Change that Caused the Problem, Try Simplifying Your Computer Configuration. If any given driver can introduce unreliability, what can you do? Try to use extremely common drivers, as they are most likely to have been better tested. In the PC world, for example, that means use the VGA video drivers, as VGA is the lowest common denominator, so to speak, of all modern video boards. Similarly, of all of the mouse drivers, the drivers for the Microsoft mouse or the Logitech are probably the most stable. Computer techies call this a vanilla configuration. Of course, not everyone will know how to go into their Windows or Macintosh configuration and choose a different set of drivers; granted, that's a more technical skill than many have—or should have to have! But, again, I explain this because if you take your computer to a repair person, dumbing down the configuration is likely to be one of the steps taken. Be Prepared to Reinstall the System's Software, if You Know How. As a computer journalist, I install a lot of software on my computer. And even if I uninstall that software, it leaves traces of itself behind, and it's not unusual to see my other applications start to behave strangely. If that sounds odd, here's a story that illustrates how one application can affect another. Part of a computer's operating system usually supports networks and computer communication—"usually" because some older operating systems have no support whatsoever for networking. Anyway, when you run a program associated with the Internet, like a Web browser, then the Web browser must rely on the operating system for its access to the Internet, just as all applications depend on the operating system for their access to printers, keyboards, and other peripherals. More specifically, the browser relies upon the operating system for something called a Windows socket or, more commonly, winsock interface. Back in the early days of Windows and DOS, Microsoft operating

Page 249

systems did not include any network support, and certainly no Internet support—Microsoft saw the Internet as a passing fad. So if you bought a browser from a company like Netscape, then Netscape not only had to include the browser in the software you bought, but also a program to supplement the operating system and supply the winsock interface. Its name was winsock.dll—DLL stands for dynamic link library, but essentially means "an addition to the operating system." By the mid-'90s, however, Microsoft started including network and Internet support in its operating systems, including Windows sockets support. Consequently, both Windows for Workgroups (a less well known version of Windows) and Windows 95 included files called winsock.dll. Where the trouble arose was when you installed Windows 95 on your system and then installed the Netscape Navigator Web browser. Navigator shipped, of course, with a file named winsock.dll, as it always had. But installing Navigator led to overwriting the Microsoft winsock.dll with Netscape's winsock.dll, leading to all kinds of software problems. Now, this kind of "dueling DLL" thing (or "DLL Hell," as it's also known) happens all the time between different pieces of software, and it's one of the reasons that I said earlier that every time you install a new piece of software in your system you may inadvertently affect (and make less reliable) the existing, previously stable software on your system. How do I handle it? I end up wiping all the data off my computer's hard disk and reinstalling the operating system, drivers, and applications on the computer about two to four times per year. There's really no easy way to deal with it, save just wiping the whole computer clean and reinstalling now and then. In fact, this very problem—the fact that installing one piece of software can affect another, already installed piece of software—is the impetus to one of the major features currently being discussed by companies like Microsoft and Apple for their future operating system releases. It's an extremely

Page 250

laudable step that'll help get us closer to where the software industry must be, closer to the kind of reliable, troublefree world that we deserve as consumers of software products. While it's an effective technique for chasing some bugs away, this may be a more technical exercise than many readers are capable of, or even willing to do; a complete system wipe and reinstall can take four or five hours. But it's often the cure for what ails your computer, and may well be worth learning how to do. Again, this is also a service that computer repair firms will do for you, but of course it'll cost some money. Useful Defensive Skills We've heard for years about how much simpler computers are now than in years gone by. They're appliances, like TVs, some say. There's no need to know how to fiddle around inside them, that's just for geeks. Wrong. Put simply, computers are still a work in progress, especially when it comes to reliability. And if you rely on one, you ought to develop a few troubleshooting and maintenance skills. That won't be true one day—one day soon, hopefully—but for now, you'll be less helpless in the face of bugs if you learn a few things. Know How to Clean Your System's Hard Disk and Reinstall All of Your Programs and Data from the Ground Up. You've just read about this. I stress this skill because in decades of working with computers the single most effective technique that I've seen for solving problems, particularly "mysterious" ones, is to just wipe the disk clean and rebuild the system's software from scratch. Know How to Back Up and Restore Your Data. As you just read, it's true that too many times a computer's operating system and drivers

Page 251

have become sufficiently unstable that there's not much to do but to clear all the data off the computer and reinstall the operating system and the applications from scratch. Most people lack the technical expertise to do that, and there's nothing wrong with that—I may be a computer expert, but I gladly let my local Texaco change my car's oil. Before I leave my car with any service station, however, I always remove anything valuable. (That, by the way, is no reflection on my Texaco guys; it's just a deeply ingrained I-grew-up-in-New-York habit.) In the same way, do you leave your data files where disaster can strike? Computer software at this time in history is buggy, flaky, and unreliable. For heaven's sake, don't trust it. Too many people buy PCs with a great printer, monitor, mouse, and keyboard—but no backup devices. Iomega's Zip drive costs about $100 dollars and lets you quickly and cheaply store 250 megabytes of data—the equivalent of about 250 books—on a special floppy disk. Tape drives are another reasonable low-cost alternative, although I find them unreliable; it's hard to go wrong with Zip drives, so I recommend them highly. Get a backup device, learn how to use it, and use it. Spend a little more if you have to, but be sure to get some kind of backup device that's easy to use—if backups aren't easy to do, they won't get done. Practice Restoring Data in Addition to Backing It Up. Over the years, I've run into a number of devices that claimed to be backing up my data, but wouldn't restore due to bugs in the backup/restore software. It may look like you'll need to back up a lot of data on a typical computer, but that's actually not true. The vast majority of the files on your computer are just program files, files copied to your computer's hard disk when you (or someone else) installed your programs. Your data files are likely to take up much less room; for example, the computer that I'm writing this on now has 741 megabytes (MB) of data on its hard drive, of which only 14 MB are my data. That leads me to the next tip:

Page 252

Put All the Files You Create—Your Data, the Documents You Create, Not the Files Automatically Installed When You Install a Program—into a Single Folder on Your Computer. The way most computer systems work, every time you install a new application, it creates a bunch of folders (some systems call these folders directories) to store the application's program files. Then, by default, the application saves any files you create—any text created by Word, any checkbook registers created by Quicken, any pictures drawn with Paintbrush—all in different directories. Word has a place for the files that you create with it, Quicken stores your checkbook in another location, and so on. The problem with this is that it makes backups and restores more complex. The fact is that the vast majority of the files on your computer are the applications' program and support files themselves, rather than anything that you created. In the event that your computer's disks must be wiped (or replaced) and all applications and operating system restored, restoring program files is easy—they came on disks with the computer, hopefully. But the things that you created are much more precious—so put them all together into a single directory. Once you know that all of your work of all kinds—pictures, words, numbers, financial records—is all sitting in a single directory, and that it's just a moment's work to back up that directory, then you'll be much more likely to actually do the backup. Then, in the event of a disaster, you just get a computer service person to restore just your applications and operating system, and you can put your personal files back onto the system easily, and you'll be back up and running. Some of the tasks here may look pretty daunting, but they aren't. Some will take a bit of practice and might require a bit of study, but they'll make you more self-reliant computerwise and more able to get vendors to give you your money's worth on your computing dollar.

Page 253

Endnotes Chapter 1 Gates quote translated from German in the German weekly magazine FOCUS (No. 43, October 23, 1995, pp. 206212). On Risks forum (http://catless.ncl .ac.uk/Risks/17.44.html) as of 25 July 1997. (This reference refers to page 1.) Therac-25: Many references. The most authoritative is probably ComputerRelated Risks (p. 68). The reader can find an excellent write-up on the Therac bug in Peterson, Fatal Defect. Addison-Wesley: Redding, MA, 1995. (This reference refers to page 3.) Montreal Life Insurance: Risks forum (http://catless.ncl.ac.uk/Risks/13.21 .html#subj4.1), 29 February 1992. Available on the Risks Web site on 8 December 1998. Patriot failure in Gulf War: Many references. The best is probably the Risks forum. (The interested reader can search Risks for all references at http://catless.ncl.ac.uk/Risks/search.html.) (This reference refers to page 4.) Macintax problems: "Intuit Finds Errors in Its Tax Software," San Francisco Chronicle, 15 February 1996. (This reference refers to page 5.) Fifteen percent of software companies shipping software that's never been tested: From a survey by Centerline Software. More details on this are in Chapter 3. Source: interview with Alyssa Dver, product marketing manager for Centerline. (This reference refers to page 6.) Wayne Rash quote: From interview with author. (This reference refers to page 9.) Comment about fearing angering Bill Gates: Said to the author by staff writer who asked to remain anonymous, for a magazine that the staff writer asked we not mention, 14 August 1997 at Moscone Conference Center in San Francisco. (This reference refers to page 9.) John Horch comment: From interview with author. (This reference refers to page 10.)

Page 254

John Murray and Wayne Rash quotes: From interviews with author. (This reference refers to page 11.) Myrhvold quotes: From "The Physicist" by Stewart Brand, appearing in Wired 3.09. (This reference refers to page 11.) Word 97 bug count: From Microsoft Knowledge Base article number Q133808, found on the September 1998 Microsoft Knowledge Base CD. The article lists the bugs; 214 is the author's count. (This reference refers to page 11.) Brad Chase quotes: From a conversation with the author at a reception for journalists in Seattle at GameWorks, 23 July 1997. (This reference refers to page 11.) Marc Sokol and Debby Meredith quotes: From phone interviews with the author in September 1997. (This reference refers to page 12.) Watts Humphrey quote: From an interview with the author, 2 August 1997. (This reference refers to page 12.) Ed Yourdon comment: From interview with author, 3 September 1997. (This reference refers to page 13.) Quote comparing low-quality software with "lemon" cars: From "Mr. S.," interview with the author. (This reference refers to page 14.) Profit rates for software firms: Microsoft returned 31 cents on the dollar, calculated from total revenue of $14,484,000,000 in 1998 and net income of $4,490,000,000 reported in year-end 1998 financial statements, found at http://www.microsoft.com/msft/ar98/fins.htm, 10 December 1998. Adobe made 20 cents on the dollar, calculated from total revenue of $911,894,000 in 1997 and net income of $186,837,000 as reported in Adobe's year-end 1997 financial statements, found at http://www.adobe.com/aboutadobe/ invrelations/PDFS/finreview97.pdf, 10 December 1998. (This reference refers to page 20.) Chapter 2 General Motors pickup truck bug: From Cem Kaner's course on software law, slide 17 (http://www.kaner.com/qwucc97/qweek.ppt). (This reference refers to page 23.) Edison information: From interview with Dr. Kidwell July 18, 1997. Grace Hopper/Bug story: Sources were myriad, but the most thorough were http://www.computer.org/50/looking/r90006.htm and http://www.texas .net/~wayne/gracel.html; also, I was fortunate enough to hear Admiral Hopper speak in the mid-80's.

Page 255

Dijkstra comment: Reported in (among other sources) http://www.cs .auckland.ac.nz/~richardg/Analyser/A-MDefs.html. (This reference refers to page 26.) Fourteen to 17 errors per thousand: Related by Craig Symonds of Microsoft, presentation: "Visual Basic 5.0 Debugging," given May 1997 in Orlando at TechEd 97, referring to typical Microsoft error rates, from author's notes. Also Peterson 1995. (This reference refers to page 27.) Algorithm derivation: From The Oxford Dictionary of English Etymology (Oxford University Press: Oxford, UK, 1966). (This reference refers to page 28.) Produce Palace International/Tec America: Computerworld, CNET (18 August 1997), http://www.news.com/News/Item/0,4,13213,00.html and http://www .news.com/News/Item/0,4,28045.00.html. (This reference refers to page 32.) Observation about disk storage savings: From "Year 2000 Problem Saved a Lot of Money 30 Years Ago," The Wall Street Journal, 6 May 97—oops, I mean 6 May 1997. (This reference refers to page 33.) Space shuttle delay: Related in Computer Related Risks (page 90). (This reference refers to page 34.) PC date loss: From author's experience, documented in computer journals in the mid- to late '80s. (This reference refers to page 35.) Leap year stories: All from Computer Related Risks (page 91). (This reference refers to page 35.) Ariane overflow problem: Documented in http://catless.ncl.ac.uk/Risks/ 18.29.html#subj 16. (This reference refers to page 37.) GPS rollover: Described at http://tycho.usno.navy.mil/gps_week.html, found 13 December, 1998. (This reference refers to page 37.) Project Mercury bug: Described in Computer Related Risks (page 27). (This reference refers to page 38.) Destruction of Mariner I six seconds after liftoff: Documented in http://catless .ncl.ac.uk/Risks/5.73.html#subj2. (This reference refers to page 39.) Chapter 3 Agana crash information: From various news sources, including Risks. (This reference refers to page 43.) Rika Matsuda story: From http://ns.gov.gu/guam/miracle. (This reference refers to page 43.) Thirty percent have no process: From Centerline study. (This reference refers to page 45.)

Page 256

Watts Humphrey ''Comments on Software Quality'' paper: Found at http://www.2bguide.com/docs/whsq.html, 13 December 1998. (This reference refers to page 46.) Watts Humphrey quotes: From telephone interview with author, August 1997. (This reference refers to page 47.) Results of using SEI process statistics: From "The Personal Software Process: Overview, Practice, and Results" by Watts Humphrey (SEI/Carnegie-Mellon University), 1995 (on-line pub.); also at http://www.sei.cmu.edu/products/ publications/95.reports/95.ar.psp.over.prac.res.html. (This reference refers to page 49.) Basili quote on Experience Factory: From A Quantitative Approach to Software Management and Engineering, chapter 1 class notes, from http://www.cs .umd.edu/~basili/. (This reference refers to page 50.) Alyssa Dver quotes: From telephone interview with author. (This reference refers to page 50.) Frank Ackerman information: From telephone interview 11 September 1997. (This reference refers to page 53.) Ed Yourdon "hero" reference: From various of his books, most recently The Rise and Resurrection of the American Programmer. Yourdon Press: Englewood Cliffs, NJ, 1997. (This reference refers to page 55.) Hackers, by Steven Levy (Delta: New York, 1984). Greenblatt and "women can't be great programmers" story, p. 84-85. "Loser" reference, page 115. (This reference refers to page 55.) Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft, by G. Pascal Zachary (The Free Press: New York, 1994). Quote from p. 113. (This reference refers to page 55.) Basili/Shelby testing versus code review story: From Fatal Defect (p. 97). (This reference refers to page 59.) Ed Yourdon comment about space shuttle software: From telephone interview with author, 3 September 1997. (This reference refers to page 61.) Pathfinder info: From telephone interview with Brian Muirhead, August 1997. (This reference refers to page 63.) Computerworld reference: From Computerworld (18 August 1997); includes one of Crumpler's quotes. (This reference refers to page 64.) Stewart Crumpler quotes: From telephone interview with author. (This reference refers to page 64.) John Murray quotes: From personal interview with author. (This reference refers to page 65.)

Page 257

James Bach quote: From "The Challenge of 'Good Enough' Software," published in http://www.stlabs.com/bach/good.htm, previously published in American Programmer (October 1995). (This reference refers to page 67.) Productivity change data: From the Bureau of Labor Statistics, Washington DC. (This reference refers to page 72.) Leamons and Madigan quotes: Referenced in text. Leamon quotes from discussion in general session, Madigan from personal interview November 1996 at Microsoft Professional Developer's Conference. (This reference refers to page 73.) Chapter 4 The current text of the copyright law is online at gopher://hamiltonl .house.gov/lld%3a/uscode/title17/sect01. (You can access this with a Web browser; gopher is an Internet system that predated the World Wide Web.) (This reference refers to page 80.) Pirated software versus legitimate sales: From "Sunset Time," by Maryfran Johnson, Computerworld (31 March 1997). (This reference refers to page 85.) Information on procedure when a complaint comes in: From telephone interview with Kim Willard of BSA, conducted by research assistant Kris Shapar, October 1997. (This reference refers to page 87.) BSA press releases about "Nail Your Boss": Several places, one example at http://www.bsa.org/pressbox/enforcement/9.16.97_2_c.html, found 28 December 1998. (This reference refers to page 90.) Corel clipart agreement: From http://www.corel.com/products/graphicsandpublishing/draw8/clipart.htm, dated 7 May 1999. (This reference refers to page 94.) Information from Consumer Project on Technology: From author's interview with director Jamie Love and staff attorney Todd Paglia 21 July 1997 and subsequent interview 11 December 1998. (This reference refers to page 97.) Assumptions in law about parties: In a contract from Kaner, http://www .kaner.com/qwucc97/qweek.ppt. (This reference refers to page 104.) Contract of adhesion info: From several sources. One is http://www.harp .org/eng/iid.txt. (This reference refers to page 104.) Step-Saver v. Wyse info: From http://www.kaner.com/qwucc97/tsld076.htm. (This reference refers to page 108.) Hill v. Gateway 2000 info: From http://cla.org/matsnpubs/memberarticles/ lawupdat.htm and Cem Kaner's Web site, www.kaner.com, source http://www .kaner.com/qwucc97/qweek.ppt. (This reference refers to page 111.)

Page 258

Background on UCC: From http://www.law.upenn.edu/bll/ulc/brochure.htm and Paglia/Love interview. (This reference refers to page 112.) Other UCC, NCCUSL, and ALI background: At http://www.webcom.com/ software/issues/guide/players.html#_Toc353089111, "The 2B Guide." (This reference refers to page 113.) ALI resolution in May 1998 meeting: From 2B Guide, http://www.2bguide.com/ali .html#98m, on ALI's site 11 December, 1998. (This reference refers to page 115.) Cem Kaner comment on bargaining: From a memo he wrote to NCCUSL on 2B. He graciously provided me with a copy. (This reference refers to page 117.) Cem Kaner, "Uniform Commercial Code Article 2B: A New Law of Software Quality," Software QA (volume 3, number 2, 1996, p. 10). (This reference refers to page 117.) SPA president's comments against nonnegotiable software licenses: From "FTC Hearings on Global and Innovation-Based Competition, testimony of Ken Wasch, President SPA, 20 December 1995." Can be found on www.spa.org/ gvmnt/papers/kentest.htm. (This reference refers to page 122.) Lotus license excerpt: From license for Ami Pro 3.1. (This reference refers to page 124.) Software reps didn't want to put licenses on Web sites reported by Ed Foster, "Software Publishers Don't Really Want Customers to See License Terms Presale," InfoWorld (30 November 1998). (This reference refers to page 126.) Ray Nimmer's remarks: From "Meeting the Information Age," an introduction to his 2B work. Can be found at http://www.lawlib.uh.edu/ucc2b/0503/ nat_issu.html. (This reference refers to page 132.) Chapter 5 Statistics on software industry: From telephone interview with Robert Holleyman, October 1997. (This reference refers to page 137.) Employment and sales info on software business: From "Building an Information Economy," Business Software Alliance, 1997. (This reference refers to page 137.) Statistics on economy as a whole: From Bureau of Labor statistics Table B- 1, "Employees on Nonfarm Payrolls by Industry," taken from http://stats.bls .gov/news.release/empsit.tlO.htm. (This reference refers to page 138.) Most numbers in the trade surpluses/deficits table come from Report FT900 (CB-96-119), Bureau of the Census, Foreign Trade Division, May 1996; software numbers from an International Data Corporation study (the Bureau of

Page 259

the Census doesn't keep numbers just for the software industry). (This reference refers to page 138.) 1996 trade statistics: From U.S. Bureau of Economic Analysis data, http://www .bea.doc.gov/bea/di/tradgsd.htm#tradexp. (This reference refers to page 138.) Seventy-five percent of shrink-wrap software made in U.S.: From Economists Incorporated, "A 20th Century Success Story: U.S. Software Industry Trends, 1987-1994," study commissioned by the BSA (page 17). (This reference refers to page 138.) Data for table of twenty largest software firms: From survey, "A World Gone Soft," The Economist, May 25, 1996. (This reference refers to page 139.) Kertzman quote: From interview at The Site (http://www.zdnet.com/zdtv/ thesite/0597wl/iview/iview544jump_050197.html), 1 May 1997. (This reference refers to page 146.) John Horch information: From telephone interview with the author, 25 August 1997. (This reference refers to page 149.) Chapter 6 Sokol quotes: From telephone interview with the author. (This reference refers to page 167.) Kertzman quotes: From telephone interview with the author. (This reference refers to page 167.) "Mr. S" quotes: From telephone interview with the author. (This reference refers to page 169.) Brad Chase quotes: from conversation at press reception at GameWorks in Seattle following Microsoft presentation to financial analysts. John DeVaan quote: From same event. (This reference refers to page 169.) John Horch quotes: From telephone interview with the author. (This reference refers to page 169.) Meredith quotes: From telephone interview with the author. (This reference refers to page 170.) Tom Campbell quotes: From personal interview with the author. (This reference refers to page 171.) Ed Yourdon quotes: From telephone interview with the author. (This reference refers to page 173.) John Murray quotes: Interview with author. (This reference refers to page 181.) Wayne Rash quotes: From personal interview with the author. (This reference refers to page 185.)

Page 260

Ed Foster quotes: From telephone interview with the author. (This reference refers to page 189.) Windows 3.1 bug number: From Cem Kaner, "The Law of Software Quality," a presentation given at Quality Week '97, and The Rise and Resurrection of the American Programmer. (This reference refers to page 199.) Numbers of minutes on hold: From "The Law of Software Quality." (This reference refers to page 199.) Bruce Brown (BugNet) quotes: From telephone interview with the author. (This reference refers to page 210.) Peter Duggan quotes: From telephone interview with author. (This reference refers to page 214.)