Category list

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.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

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.

1.2 The six ways of thinking

This book explores methods for debugging, organized according to six intellectual disciplines:

The way of the detective
The way of the mathematician
The way of the safety expert
The way of the psychologist
The way of the computer scientist
The way of the engineer

Each way has an analogy, a set of assumptions that forms a worldview , and a set of techniques associated with it. We follow a multidisciplinary approach, in which we seek the best methods for solving intellectual problems.

When we follow the way of the detective, we use an analogy between the search for the culprit in a murder mystery and the search for a software defect in a program. The defect is treated as a crime, and the programmer is the detective. A detective who wants to solve a crime must determine the answers to several important questions:

Who did it?
{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}
How did the culprit do it?
When did the culprit do it?
Why did the culprit do it?

We seek similar answers for software defects.

When we follow the way of the mathematician, we use an analogy between developing a proof of a mathematical proposition and developing a diagnosis of a software defect in a program. In the past several centuries, mathematicians have developed numerous methods for constructing proofs. These methods, however, have only recently been organized and taught in a way that the average student can learn and apply as effectively as the mathematically gifted.

When we follow the way of the safety expert, we use an analogy between accidents or critical events and failures of software to behave as expected. The defect is considered a critical event, and the programmer is the safety analyst. The safety expert seeks to prevent future problems by analyzing the causes of significant events, such as accidents, near misses, and potential problems.

When we follow the way of the psychologist, we recognize that software defects are the result of human error. Human error has recently become an area of study for cognitive psychologists. The information-processing model used by many psychologists provides a means to explain how humans make mistakes.

When we follow the way of the engineer, we use an analogy between the design of reliable material objects and the design of reliable immaterial software. Engineers follow a standard process for creating physical objects. We can leverage the methods that can prevent or identify defects that are introduced during phases of the software-development process. Engineers design useful objects by following standards, and we suggest ways to prevent software defects by following standards.

When we follow the way of the computer scientist, we treat defective software as processes that fail to manipulate symbols correctly. Computer scientists study symbol manipulation by digital electronics. Some of the theoretical concepts of computer science for classifying and analyzing information can be applied to the process of debugging. Computer scientists advance their discipline by inventing layers of tools that can be composed into larger systems. When we follow the way of the computer scientist, we look for tools that can automatically diagnose software defects.