Insecure Software's Real Cost: Software and Cement

Software has become crucial to the very survival of civilization. But badly written, insecure software is hurting people...and costing businesses and individuals billions of dollars every year. In "Geekonomics," David Rice shows how we can change it. Read our excerpt from the book.

1 2 3 Page 2
Page 2 of 3

Software is everywhere; it is everywhere because software is the closest thing we have to a universal tool. It exhibits a radical malleability that allows us to do with it what we will. Software itself is nothing more than a set of commands that tells a computer processor (a microchip) what to do. Connect a microchip to a toy, and the toy becomes "smart;" connect a microchip to a car's fuel injector, and the car becomes more fuel efficient; connect it to a phone, and the phone becomes indispensable in life's everyday affairs. Connect a microchip to just about anything, and just about anything is possible because the software makes it so. Software is the ghost in the machine, the DNA of technology; it is what gives things the appearance of intelligence when none can possibly exist.

The only aspect of software more impressive than software itself is the people that create software. Computer programmers, also known as software developers or software engineers, write the instructions that tell computers what to do. Software developers are in large part a collection of extremely talented and gifted individuals whose capacity to envision and implement algorithms of extraordinary complexity and elegance gives us search engines, operating systems, word processors, instant messaging, mobile networks, satellite navigation, smart cars, advanced medical imaging; the list goes on. As such, software is a human creation, and as a human creation it is subject to the strengths and foibles of humanity. This is where the similarities of cement and software become most interesting.

Software, like cement before it, is becoming the foundation of civilization. Our very lives are becoming more dependent on and subject to software. As such, the properties of software matter greatly: quality, reliability, security, each by themselves accomplish very little, but their absence faults everything else. Like Portland cement, software can be unreliable if production processes vary even slightly. Whereas variations in kiln temperatures, mixture ratios, or grinding processes can detrimentally affect the strength and durability of Portland cement after it has been poured, there are a host of similar, seemingly trivial variations in producing software that can detrimentally affect its "strength" when "poured" into microchips. It is up to humans to get the production process right.

Unlike Portland cement, for more than 50 years software of all types and function has been continuously released into the stream of commerce, plagued by design and implementation defects that were largely detectable and preventable by manufacturers, but were not. This has and does result in catastrophic accidents, significant financial losses, and even death. The trepidation over insufficient software manufacturing practices extends back to the late 1960s when the North American Treaty Organization (NATO) convened a panel of 50 experts to address the "software crisis." While the panel did not provide any direct solutions, the concept of a "software engineer" was developed as a means to more closely align software manufacturing with the engineering discipline rather than artistic creativity. The intent, as far as we can tell, was to remove the "rule of thumb" in the production of software and all the inconsistencies such approximation introduces. After 50 years, defining what actually constitutes the principles and practice of software engineering has not progressed far. What is clear, however, is that the unfortunate history of software blunders sullies the reputation of software in general and distorts the genius of software developers in particular.

What is clear, however, is that the unfortunate history of software blunders sullies the reputation of software in general and distorts the genius of software developers in particular.

Perhaps most frustrating is the inconsistent use of quality control measures by such a wide range of software manufacturers for such an extended period of time. Software is infinitely more complex than cement to be sure, but complexity does not entirely account for systemic, reoccurring software manufacturing defects. Quality control measures—even in the absence of a clear definition for software engineering—have been and are available specifically to address problems with software production.

Software has its own modern-day equivalent of Joseph Bazalgette: his name is Watts Humphrey. Humphrey is a fellow and research scientist at Carnegie Mellon University's Software Engineering Institute (SEI) and is often called the "father of software quality" having developed numerous methodologies since the 1980s for designing quality and reliability into software products. In 2005, President George W. Bush awarded Mr. Humphrey the National Medal of Technology, the highest honor for innovation in the United States. The only problem in this story is that a significant portion of software manufacturers around the world still largely ignore or only superficially implement Humphrey's guidance. As a result, the Software Engineering Institute noted at the beginning of the twenty-first century that software was getting worse, not better. Such a proclamation augurs ill for civilization's newest foundation.

But if software quality were the only issue, perhaps we could discount the problem of low-quality software simply on the basis of "growing pains." After all, at 50 years old, some might argue software is still a relatively new phenomenon and that such failures in quality are understandable and even tolerable for such a young technology. When civil engineering was 50 years old, for instance, the brick had not even been invented yet.9

Yet when civil engineering was 50 years old, the profession was not building and connecting global infrastructure. Software's newness has not precluded it from being injected into nearly every aspect of modern civilization. That software connects everything to everything else magnifies even the smallest foibles in software production. This introduces a critical aspect of software vastly different from weaknesses in traditional building materials: once interconnected, even the smallest piece of insecure software may have global consequences. New or not, software needs to be worthy of its place.

Weaknesses or defects in software can not only result in a given software application failing for one reason or another (including no reason), but software defects can potentially be exploited by hackers, who, discovering or knowing the weakness exists, may use it to surreptitiously access and control a system from a continent away, stealing sensitive personal information such as credit cards or social security numbers or absconding with trade secrets or intellectual property. Such weaknesses could also be used to hijack computer systems and then turn those systems against their owners or against other nations and other peoples. In the end, insecure software is right now resulting in economic and social costs that are now well into billions of dollars per year with no sign of abatement. The trend is disturbing.

Understanding why this situation persists and seems to be only getting worse has important implications for modern civilization. In other words, new or not, society inevitably demands any technology used in the foundation of civilization, whether cement or software, should be given the time and attention foundations deserve. Bazalgette and his legacy expected no less; nor should we.

In the Shadow of Utility

The litany of documented software failures is extensive and tragic.10 It does not take much effort to find examples of software failures resulting in loss of life, limb, money, time, or property. The trend only promises to become worse as software becomes more critical to almost every aspect of modern life; yet, software manufacturers enjoy an astonishing amount of insulation from government oversight, legal liability, consumer retaliation, and indeed, as some critics have observed, engineering skill. A proven record of significant, costly, and deadly failures with no significant decline in use by its victims is baffling. On top of—in fact, despite—these shortcomings, victims (consumers, corporations, and governments included) lavishly spend on acquiring and defending a clearly defective product. Why?

Software manufacturers enjoy an astonishing amount of insulation from government oversight, legal liability, consumer retaliation, and indeed, as some critics have observed, engineering skill.

    Why do software manufacturers continue to produce and consumers continue to purchase unreliable and insecure software?

    Why do software users willingly and repeatedly accept licensing agreements that absolve software manufacturers of most forms of liability for any design or application defects that might result in injury, harm, or damages?

    Why do governments make so few demands on software manufacturers while placing onerous compliance requirements on software buyers, who are least qualified to address the problems associated with software manufacturing?

    Why should software not be subject to the same public policy concerns applied to other critical elements of national infrastructure?

    Why do chickens cross the road?

Each of these questions is answered in part by this simple response: to maximize utility. We all do things that might appear perfectly acceptable in our own eyes that might appear perfectly crazy to someone else. A chicken crossing the road in the presence of drivers who may be willing to flatten the poor thing simply to interrupt the monotony of driving might appear rather crazy to an outside observer. In fact, from an economist's perspective, this is perfectly rational behavior on the part of the chicken so long as the chicken believes it will be better off for the crossing. Jumping out of an airplane with a parachute might seem perfectly crazy to observers, unless the skydiver believes they are better off for the jumping. Likewise, software buyers continuing to accept software licensing terms that put them at a distinct disadvantage legally, financially, or personally should the software fail might appear perfectly baffling, unless buyers believe they will be better off for the accepting.

Economists use the notion of utility to help explain why people behave the way they do. The concept of utility is a little like the concept of "happiness" only more general. I explain the concept of utility in more detail in Chapter 2, "Six Billion Crash Test Dummies," but sufficed to say, utility centers around the notion that most of us want to make our lives better, and that many of our life decisions are probably based on this desire. Software inarguably makes our life better, but like crossing the road or jumping out of an airplane or owning a swimming pool, everything has a cost.

It is not always the utility we get out of something or some activity that matters most, but how much it potentially costs us. Costs are not always obvious to the individual at time of "purchase" so to speak, and can be hidden or otherwise obscured. In general, cost can be measured in private terms, what it directly costs an individual to behave in a certain way, or measured in social costs, what it costs society for an individual to undertake a certain activity. The balance of private and social costs is the focus of many public policy efforts.

The private cost of smoking, for instance, is relatively low monetarily from an individual's view point, but can impose substantial social costs due to the prolonged medical services associated with caring for long-term chronic smokers. Imposing a cigarette tax is but one way to raise the private cost of an activity in order to deter the behavior, which thereby potentially reduces the social cost by reducing the total number of smokers in the population and how much they smoke.

People's evaluation of utility versus cost can lead to some fairly interesting situations. As a case in point, in the United States swimming pools kill or injure more children under the age of 14 than firearms. At 16 percent, accidental drowning was the second leading cause of injury-related death of children aged 14 and under in 2004 (car accidents ranked first); compare this with only 1 percent of children that died due to accidental discharge of firearms.11 In fact, injury-related death due to accidental discharge of firearms ranks at the bottom of all other causes of death and injury among children including choking (17 percent), fire and burns (10 percent), and bicycle accidents, poisoning, and falls (each at 2 percent).

There are plenty of people, and parents in particular, who might forbid children playing at the home of a neighbor who possesses one or more firearms, but the likelihood of a child drowning at a neighborhood pool party is far higher than a child being injured or killed by the firearm of a neighbor. Yet few parents espouse an anti-swimming pool sentiment or join anti-swimming pool action groups as they would for firearms, even though statistics would certainly warrant such behavior. The rather simplistic answer to this incongruency is that a larger portion of the population sees the intrinsic utility of a swimming pool over and above the utility of possessing a hand gun. Yet a swimming pool incurs a much higher cost to both families and society than do firearms. Even things with obvious utility like a swimming pool can have a dark shadow.

Played out against this background of people's desire for utility (and not always recognizing the real cost), is the story of software. The questions at the start of this section really touch on the issues of self-interest and, more importantly, the incentives we have as individuals to undertake certain activities and the utility we derive. Understanding incentives also gives us a possible foundation to address the issues of why software manufacturing seems to be in the state it is in. If it is up to humans to get the production processes for Portland cement and software correct, then it is just as important, if not more so, to understand why humans behave as they do. Incentives are a good place to start.

1 2 3 Page 2
Page 2 of 3
Discover what your peers are reading. Sign up for our FREE email newsletters today!