Introduction A while back, I was given a list of books to read in order to become a world class software engineer. I have done previous reviews here. One of these books is Why Programs Fail A Guide to Systematic Debugging by Andreas Zeller.

As experienced engineers may know debugging is an important aspect of our jobs. In complex codebases, this may form the majority of our work. Unfortunately, it isn’t something that is usually taught in degrees and bootcamps and we must learn it through practical experience whilst on the job.

This book helps to ease our task by introducing us to techniques used in debugging. The book is divided into 15 chapters. Each chapter is divided into 5 sections.

The first section discusses the title of the chapter in detail, the second the core concepts that software engineers should take, the third the tools to use, the fourth points to what we can also read and the final is a number of exercises to do.

How Do Bugs Arise? In my experience, bugs are usually caused by incorrect assumptions about the code. Due to programmers being under tight deadlines, bugs are usually discovered by end users. They can usually be very costly. The author discusses this briefly at the end of chapter 1.

The first chapter discusses how failures in software arise. The author thinks it takes place in 3 stages: i) The programmer creates a defect in the programming code. ii) The defect causes an infection in the programming state iii) The infection causes a failure-an externally observable failure.

The author lists a series of steps with the acronym TRAFFIC to debug a program. i) Track: Create a problem in the programming database. In the second chapter, the author discusses how to keep track of the problems. ii) Reproduce: Reproduce the failure.This is discussed in chapter 4. iii) Automate: Automate and simplify the test case. iv) Find Origins: Follow back the dependencies from the failure to possible infection origins. v) Focus vi) Isolate: Use the scientific method (see Chapter 6) to isolate the origin of the infection. Continue isolating origins transitively until you have an infection chain from defect to failure. vii) Correct: Remove the defect and verify the success of your fix.

How to fix bugs? As experienced developers know, there can be a number of issues that may arise when fixing a bug. First, we need to know whether the issue is truly fixed. To do this we may a correct understanding of the problem (the problem database mentioned above). Secondly, we need to also ensure that the fix doesn’t cause any more problems.

My approach to debugging which has been gathered from working on different codebases over the years is to understand the problem, read the codebase, understand the workflow using logging statements, make the fix and adapt so that nothing else is broken, verify that the fix works using unit and integration testing and verify that nothing else has been broken running previous unit and integration tests.

Whilst this does work, it can be time consuming. The author makes a series of recommendations throughout the book that involves both tools and techniques to make the process more efficient.

The tools he suggests are debuggers and one of the techniques is an adaptation of the scientific method in a process known as scientific debugging. The steps in this method are i) Observe a failure. ii) Invent a hypothesis as to the failure cause that is consistent with the observations. iii)Use the hypothesis to make predictions. iv)Test the hypothesis by experiments and further observations. v) Repeat steps 3 and 4 until the hypothesis can no longer be refined.

Applying the scientific debugging should help the programmer to find the issue. The author spends a number of chapters discussing in detail how to do so. Once this is done, we must fix the problem. The author discusses in chapter 15.

As I mentioned above, we need to verify the fix resolves the problem and that it doesn’t cause new problems. Other books discuss how to do this. Experienced engineers should recognize that testing will help with both.

Conclusion This is a valuable, practical book. It is well organized and the summaries at the end of each chapter make it easy for programmers to refer to if they should forget or to get summaries of the main deductions. I recommend this book for all software engineers from novices to seniors.