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.⁹

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.¹⁰ 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.