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 engineer
The way of the computer scientist
Each way has an analogy, a set of assumptions that forms a worldview, and a set of techniques associated with it. A symptom is an observable difference between the actual behavior and the planned behavior of a software unit. A defect is that aspect of the design or implementation that will result in a symptom.
Testing is the process of determining whether a given set of inputs causes a nonacceptable behavior in a program. Debugging is the process of determining why a given set of inputs causes a nonacceptable behavior in a program and what must be changed to cause the behavior to be acceptable.
The craft of software engineering has gone through several eras. These eras can be identified by the books published promoting the main ideas of each particular era. In each era, the basic concepts of that era were applied to the various phases of the software-development life cycle. The various structured disciplines were concerned with organizing computation with respect to actions. In contrast, the object-oriented disciplines are concerned with organizing computation with respect to data.
There are no books addressing structured debugging or object-oriented debugging. This seems odd, since the structured and object-oriented approaches have been applied to every other facet of the software-development life cycle.
Coding, designing, analyzing, and testing are all constructive activities. Debugging is primarily a cognitive activity. The cognitive psychology of human error, induction, and deduction did not become widely understood until the early 1990s. Books that documented the mathematical problem-solving process did not become widely available until the mid-1980s. These disciplines provide important insights into the debugging process.
Programming students start with debugging by editing, then move on to debugging by interacting, and then graduate to debugging by repeating. Debugging by Thinking is different from all of these approaches because it provides an explicit methodology that uses a multidisciplinary approach and makes the programmer self-aware as he or she works.