Chapter 1: Introduction

If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization.

—Gerald Weinberg

1.1 The nature of the problem

I don’t believe that the story of a moth found in a relay of one of the first digital computers adequately explains why software defects are commonly referred to as bugs. Books on debugging often begin with a recitation of how Adm. Grace Hopper found a moth, which had shorted out an electronic relay, in the Mark II computer. While the story may be true and although there are many variations told, the aptness of the term goes far deeper than this incident.

The word “bug” is commonly used to refer both to insects and arachnids. In the natural world, bugs are often the chief competitors of human-kind. Scientists speculate that if humans became extinct, bugs would become the dominant life form on the planet. According to the Bible, three of the ten plagues that God visited on Egypt, to free the Israelites from slavery, were visitations of bugs (gnats, flies, and locusts). Bugs bite us, sting us, destroy our houses, consume our food, and transmit to us many of the worst diseases that afflict humanity.

Software bugs afflict people in very similar ways. Like natural bugs, they’re everywhere. Almost all interesting software has bugs, and most interesting software has far too many bugs. Like natural bugs, they cause irritation and even pain when we encounter them. Now that computer chips are embedded in so many devices, software bugs can threaten human life and property. Calling software defects “bugs” resonates with us at a deep level. This is because software defects are becoming as troublesome as insects and arachnids have been in the past.

There are many reasons why today’s software has so many defects. One reason is that many programmers aren’t very good at debugging. Some programmers look on the debugging phase of the software life cycle with the same enthusiasm they show for filling out their income tax forms.

The purpose of this book is to reduce the effort programmers expend to diagnose software bugs. If the time available to debug remains constant in a project, this efficiency improvement will reduce the total number of bugs in a software program. If the number of outstanding bugs remains constant in a project, this efficiency improvement will reduce the time it takes to deliver that software. Either way, the person who benefits is the ultimate user of the program.

1.1.1 Definitions

It’s important to use a consistent set of terms when studying a subject. We will use the term symptom to mean an observable difference between the actual behavior and the planned behavior of a software unit. The IEEE94 Software Engineering Standards [IEEE94] refer to this as a failure.

We will use the term defect to mean that aspect of the design or implementation that will result in a symptom. The IEEE94 Software Engineering Standards refer to this as a fault. We will use the term bug interchangeably with defect.