Debugging by Thinking

A Multidisciplinary Approach

Robert Charles Metzger

• Publisher: Digital Press
• Year: 2003
• ISBN:
  9780080503813
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

Debugging by Thinking: A Multi-Disciplinary Approach is the first book to apply the wisdom of six disciplines—logic, mathematics, psychology, safety analysis, computer science, and engineering—to the problem of debugging. It uses the methods of literary detectives such as Sherlock Holmes, the techniques of mathematical problem solving, the results of research into the cognitive psychology of human error, the root cause analyses of safety experts, the compiler analyses of computer science, and the processes of modern engineering to define a systematic approach to identifying and correcting software errors.* Language Independent Methods: Examples are given in Java and C++
* Complete source code shows actual bugs, rather than contrived examples
* Examples are accessible with no more knowledge than a course in Data Structures and Algorithms requires
* A "thought process diary" shows how the author actually resolved the problems as they occurred

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

1.2 The six ways of thinking

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

1. The way of the detective

2. The way of the mathematician

3. The way of the safety expert

4. The way of the psychologist

5. The way of the computer scientist

6. 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?

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