Browse Books

Reviewer: Fernando Berzal

Sadly, debugging is an often neglected topic in software engineering education. Although preventing errors in the first place is certainly desirable, to err is human, to rectify is wise, and to learn from mistakes is a must. From the creator of the GNU data display debugger, better known by its reiterative acronym, Why programs fail attempts to provide a systematic approach to finding, reproducing, and fixing programming errors, with a strong focus on the automation of many debugging techniques. Even though "there is no chance of an automated device that determines the defects" (in a software program), "we can come very close to the defects-and close to a good explanation of how the failure came to be" as long as we can automatically isolate potential causes. Before delving into the details of debugging techniques, Zeller covers some prerequisites every software developer should be acquainted with. In particular, problem-tracking systems are discussed, not only as tools for tracking and managing problem reports, but also as valuable idea repositories and requirements management systems. Testing techniques are also addressed in their own chapter. Here, the focus is on how to set up automated tests that support debugging tasks by isolating failing units and making failures reproducible. Once the stage is set, Zeller explores the debugging process in depth. After tracking the problem in the database, the first task in debugging is reproducing the failure as stated in the original problem report. It provides the foundation the debugging process is built upon. Apparently straightforward, this task can be harder than it seems, as shown by heisenbugs, where debugging tools interfere with the problem so that it disappears when it is being observed. Once you have a reproducible problem, you can proceed and simplify it with delta debugging [1], an automated method to simplify test cases. Debugging then consists of obtaining a theory that explains the bug (that is, a diagnosis). Zeller advocates for the application of the scientific method: reasoning about programs to create hypotheses, and performing experiments to validate or discard those hypotheses. He also suggests the use of a debugging logbook to make debugging explicit by writing down all hypotheses and observations. It relieves memory stress on the observer, and, what might be more important, it banishes the view of debugging as a black art. The core of the book deals with techniques for creating hypotheses and determining the failure causes of observed problems. Roughly speaking, they can be grouped into four groups. Deductive techniques cover the whole gamut of static analysis tools, from program slicing to specialized code smell detectors. Most debugging techniques, however, are dynamic by nature. Observational techniques include logging, dynamic slicing, using debuggers, and introducing assertions to automatically detect contract infringements and also to discard infection sites. Inductive techniques, such as coverage comparison or dynamic invariants, help make debugging more efficient by focusing on aspects of a failing run that differ from normal passing runs. Efficiency is also the focus of experimental techniques that try to automate the search for failure causes and failure-inducing program states. In summary, this is an outstanding practical book where many interesting ideas are explored. In the near future, we may see many of them integrated within our development environments. Some of them, such as delta debugging, are already available as plug-ins to existing integrated development environments and are purportedly being used by early adopters. Even though they might not be ready for a wider audience yet, they provide a wider perspective on debugging. If you would like to improve your detective skills as a programmer, this is certainly the book to read. Online Computing Reviews Service