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

As such, Geekonomics is not so much the story of software told through the lens of technology, but through the lens of humanity, specifically the incentives for manufacturing, buying, and exploiting insecure software. Economics is simply one way of understanding why humans behave as they do. But if economics is generally described as "the dismal science," then software engineering is economics' freakish, serotonin-deprived cousin. Economics is positively cheery and approachable in comparison. To date, the discussion regarding software has been largely dominated by technology experts whose explanations largely serve to alienate the very people that are touched most by software. Us.

Yet the congress of these two disciplines tells an important and consequential story affecting both the reader's everyday life and the welfare of the global community. The issue of insecure software is at least as much about economics as it is about technology. And so I discuss both in this book. This book is not intended to be a comprehensive economics text, a litany of software failures (although this is sometimes inevitable), a diatribe as to how the world is coming apart at the seams, or a prophecy that civilization's ultimate demise will occur because of "bad" software. Prophesizing disaster is cliché. Bad things happen all the time, and forecasting tragic events does not require an exceptional amount of talent, intelligence, or foresight. If anything, the world tolerates disaster and somehow still makes progress. This does not mean valid threats to economic and national stability due to "bad" software are illusory or should be minimized. On the contrary, the story of insecure software has not been readily approachable and therefore not well understood. We cannot manage what we do not understand, including ourselves. Software is a ghost in the machine and, at times, frustratingly so. But as software is a human creation, it does need to remain a frustrating ghost.

My intent in this book is to give this story—the story of insecure software—a suitable voice so that readers from any walk of life can understand the implications. I promise the reader that there is not a single graph in this book; nor is there a single snippet of code. This story should be accessible to more than the experts because it is we who create this story and are touched by it daily. The consequences are too great and far-reaching for the average person to remain unaware.

The first task of Geekonomics, then, is to address the questions presented at the beginning of this section as completely as possible within the confines of a single book. This means some aspects may be incomplete or not as complete as some readers might prefer. However, if anything, the story of software can be entertaining, and this book is intended to do that as well as inform and enlighten.

The second and more difficult task of Geekonomics is to analyze what the real cost of insecure software might be. Swimming pools can have a high cost, but how costly is insecure software, really? This is a challenging task considering that unlike statistics regarding accidental drowning, good data on which to base cost estimates regarding insecure software is notoriously lacking and inaccurate for two reasons. First, there is presumed to be a significant amount of underreporting given that many organizations might not realize they have been hacked or do not want to publicly share such information for fear of consumer retaliation or bad publicity. Second, actual costs tend to be distorted based on the incentives of those reporting their losses. For some victims, they may tend to inflate losses in an effort to increase their chances of recovering damages in court. Other groups of victims might deflate costs in an effort to quell any uprisings on the part of customers or shareholders. Law enforcement and cyber security companies can tend to inflate numbers in an effort to gain more funding or more clients, respectively. Whatever the incentives might be for reporting high or low, somewhere within these numbers is a hint to what is actually going on.

The third and final task of Geekonomics is to identify current incentives of market participants and what new incentives might be necessary to change status quo. One alternative is always choosing to do nothing; simply let things work themselves out on their own, or more accurately, let the market determine what should be done. This book argues against such action. Any intervention into a market carries with it the risk of shock, and doing nothing is certainly one way of avoiding such risk. But intervention is necessary when a condition is likely to degenerate if nothing is done. The magnitude of the risk is great enough and the signs of degeneration clear enough that new and different incentives are needed to motivate software manufacturers to produce and software buyers to demand safer, higher quality, and more secure software.

Fragile Analogies

Writing a book is far easier than writing software. If the text in a book should have "bugs" such as ambiguities, inconsistencies, or worse, contradictions, you the reader might be annoyed, even angry, but you will still have your wits about you. Simply shrug your shoulders, turn the page and read on. This is because, as a human, you are a perceptive creature and can deal to a greater or lesser extent with the paradoxical and ambiguous nature of reality. Computers are not nearly so lucky. As Peter Drucker, a legendary management consultant, pointed out in The Effective Executive more than 40 years ago, computers are logical morons. In other words, computers are stupid. This is the first important realization toward protecting modern infrastructure. Computers are stupid because logic is essentially stupid: logic only does what logic permits.¹² Computers do exactly as they are instructed by software, no more and no less. If the software is "wrong," so too will be the computer. Unless the software developer anticipates problems ahead of time, the computer will not be able to simply shrug, turn the page, and move on.

Computers cannot intrinsically deal with ambiguity or uncertainly with as much deft and acumen as humans. Software must be correct, or it is nothing at all. So whereas humans live and even thrive in a universe full of logical contradictions and inconsistencies, computers live in a neat, tidy little world defined by logic. Yet that logic is written primarily by perceptive creatures known as software developers, who at times perceive better than they reason. This makes the radical malleability of software both blessing and bane. We can do with software as we will, but what we will can sometimes be far different than what we mean.

The radical malleability of software also poses additional explanatory complications. Software is like cement because it is being injected into the foundation of civilization. Software is also like a swimming pool because people opt to use it even though statistics tend to show the high private and social costs of its use. In fact, in this book, software is described to be like automobiles, DNA, broken windows, freeways, aeronautical charts, books, products, manuscripts, factories, and so on. Software might even be like a box of chocolates. You never know what you're going to get. With software, all analogies are fragile and incomplete.

Cement is an imperfect analogy for software, but so too is just about everything else, which means analogies used to understand software tend to break quite easily if over-extended. The radical malleability of software means any single analogy used to understand software will be somewhat unsatisfying, as will, unfortunately, any single solution employed to solve the problem of insecure software. As a universal tool, software can take far too many potential forms for any one analogy to allow us to sufficiently grasp software and wrestle it to the ground. This challenge is nowhere more obvious than in the judicial courts of the United States, which reason by analogy from known concepts.¹³ This does not mean that software cannot be understood, simply that significantly more mental effort must be applied to think about software in a certain way, in the right context, and under the relevant assumptions. As such, this book may liberally switch between analogies to make certain points. This is more the nature of software and less the idiosyncrasies of the author (or at least, I would hope).

Finally, there are many different kinds of software: enterprise software, consumer software, embedded software, open source software, and the list goes on. Experts in the field prefer to distinguish between these types of software because each has a different function and different relevancies to the tasks they are designed for. Such is the radical malleability of software.