Skip to content

Four Books on Debugging

It often seems like the ability to debug complex problems is not distributed very evenly among programmers. No doubt there’s some truth to this, but also people can become better over time. Although the main way to improve is through experience, it’s also useful to keep the bigger picture in mind by listening to what other people have to say about the subject. This post discusses four books about debugging that treat it as a generic process, as opposed to being about Visual Studio or something. I read them in order of increasing size.

Debugging, by David Agans

At 175 pages and less than $15, this is a book everyone ought to own. For example, Alex says:

Agans actually sort of says everything I believe about debugging, just tersely and without much nod in the direction of tools.

This is exactly right.

As the subtitle says, this book is structured around nine rules. I wouldn’t exactly say that following these rules makes debugging easy, but it’s definitely the case that ignoring them will make debugging a lot harder. Each rule is explained using real-world examples and is broken down into sub-rules. This is great material and reading the whole thing only takes a few hours. I particularly liked the chapter containing some longer debugging stories with specific notes about where each rule came into play (or should have). Another nice chapter covers debugging remotely—for example from the help desk. Us teachers end up doing quite a bit of this kind of debugging, often late at night before an assignment is due. It truly is a difficult skill that is distinct from hands-on debugging.

This material is not specifically about computer programming, but rather covers debugging as a generic process for identifying the root cause of a broad category of engineering problems including stalled car engines and leaking roofs. However, most of his examples come from embedded computer systems. Unlike the other three books, there’s no specific advice here for dealing with specific tools, programming languages, or even programming-specific problems such as concurrency errors.

Debug It! by Paul Butcher

Butcher’s book contains a large amount of great material not found in Agans, such as specific advice about version control systems, logging frameworks, mocks and stubs, and release engineering. On the other hand, I felt that Butcher did not present the actual process of debugging as cleanly or clearly, possibly due to the lack of a clear separation between the core intellectual activity and the incidental features of dealing with particular software systems.

zeller

Why Programs Fail, by Andreas Zeller

Agans and Butcher approach debugging from the point of view of the practitioner. Zeller, on the other hand, approaches the topic both as a practitioner and as a researcher. This book, like the previous two, contains a solid explanation of the core debugging concepts and skills. In addition, we get an extensive list of tools and techniques surrounding the actual practice of debugging. A fair bit of this builds upon the kind of knowledge that we’d expect someone with a CS degree to have, especially from a compilers course. Absorbing this book requires a lot more time than Agans or Butcher does.

debugging_by_thinkingDebugging by Thinking, by Robert Metzger

I have to admit, after reading three books about debugging I was about ready to quit, and at 567 pages Metzger is the longest of the lot. The subtitle “a multidisciplinary approach” refers to six styles of thinking around which the book is structured:

  • the way of the detective is about deducing where the culprit is by following a trail of clues
  • the way of the mathematician observes that useful parallels can be drawn between methods for debugging and methods for creating mathematical proofs
  • the way of the safety expert treats bugs as serious failures and attempts to backtrack the sequence of events that made the bug possible, in order to prevent the same problem from occurring again
  • the way of the psychologist analyzes the kinds of flawed thinking that leads people to implement bugs: Was the developer unaware of a key fact? Did she get interrupted while implementing a critical function? Etc.
  • the way of the computer scientist embraces software tools and also mathematical tools such as formal grammars
  • the way of the engineer is mainly concerned with the process of creating bug-free software: specification, testing, etc.

I was amused that this seemingly exhaustive list omits my favorite debugging analogy: the way of the scientist, where we formulate hypotheses and test them with experiments (Metzger does discuss hypothesis testing, but the material is split across the detective and mathematician). Some of these chapters—the ways of the mathematician, detective, and psychologist in particular—are very strong, while others are weaker. Interleaved with the “six ways” are a couple of lengthy case studies where buggy pieces of code are iteratively improved.

Summary

All of these books are good. Each contains useful information and each of them is worth owning. On the other hand, you don’t need all four. Here are the tradeoffs:

  • Agans’ book is The Prince or The Art of War for debugging: short and sweet and sometimes profound, but not usually containing the most specific advice for your particular situation. It is most directly targeted toward people who work at the hardware/software boundary.
  • Butcher’s book is not too long and contains considerably more information that is specific to software debugging than Agans.
  • Zeller’s book has a strong computer science focus and it is most helpful for understanding debugging methods and tools, instead of just building solid debugging skills.
  • Metzger’s book is the most detailed and specific about the various mental tools that one can use to attack software debugging problems.

I’m interested to hear feedback. Also, let me know if you have a favorite book that I left out (again, I’m most interested in language- and system-independent debugging).

{ 9 } Comments

  1. Pierre Rasmussen | March 1, 2013 at 2:44 am | Permalink

    Great post!

    I have Agan’s and Zeller’s books in my own bookshelf and I agree with your reflections, and I like agans more than Zellers.

    I belive its impossible to write a book about how to become a master in debugging. As you point out, debugging is a generic process, and from books you can get a kick-start in the basics principles. Which tools you then use or what typical errors you can start look for depends very much on the product you are debugging.

    I must recomend a book which are both entertaining and education, especially if you are working with embedded systems.

    If I Only Changed the Software, Why is the Phone on Fire?: Embedded Debugging Methods Revealed: Technical Mysteries for Engineers
    by Lisa Simone

    As a reader you follow a team tackling different issues (chapters) like a fly one the wall. Each chapter has different difficaultys and ends with a summary and tips. In each chapter there is alsoe a “reader instructions” asking you if you can solve the bug before the team with the presented material. Very fun!

    BR

    // Pierre

  2. pm215 | March 1, 2013 at 4:59 am | Permalink

    You don’t say much in your reviews about target audience. Do you feel these books are mostly aimed at students or junior engineers, or is there useful new information in them even for somebody who’s been programming and debugging for a decade?

    (Can’t resist the opportunity to repeat one of my favourite computing quotes, by Maurice Wilkes: “the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs”…)

  3. reno | March 1, 2013 at 7:46 am | Permalink

    > the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs

    Lucky him! For most of us, it’s finding errors in *other’s* programs.

  4. Fernando | March 1, 2013 at 9:01 am | Permalink

    I agree with the other comment: “If I only changed the software why is the phone on fire?” is a great book which also includes real world excersices with they answers.

  5. Alex Groce | March 1, 2013 at 12:10 pm | Permalink

    I haven’t read Butcher or Metzger yet (though they are both on my shelf), but I suspect everyone who is serious about debugging should probably read Agans. If you are at all interested in the academic or research sides of debugging, Zeller is good, but it is a book aimed at either the more theoretical practitioner or the more practical researcher, not any random programmer.

    I would say that for people who have been debugging for a long time, Agans is excellent for helping you really drill into your head some rules that it is very tempting to not follow in many situations. This is good because most of the rules, most of the time, protect you from a really bad debugging disaster. At worst they slow you down a small amount on a trivial and easy debug session.

    Zeller certainly has a lot to say that is not going to be old, well-covered ground for the long-time debugging expert, unless you are incredibly well-versed in all the tools lying around, and the academic literature on the subject.

    Do any of the books other than Andreas’ actually cover delta-debugging? The idea of divide and conquer is in Agans, but the actual mechanics of implementing it in a way that works well in a wide variety of software testing situations are missing. That matters because I’ve run into a lot of skilled engineers who (1) want divide and conquer (2) understand the idea of “toolizing” it and (3) are frustrated with the actual practical results. In several cases, just pointing people at delta-debugging has been extremely helpful.

    Barr’s _Find the Bug_ isn’t “about” debugging, but is a nice way to develop offline debugging skills.

  6. regehr | March 1, 2013 at 1:27 pm | Permalink

    Pierre and Fernando, thanks for the book recommendation, it looks great and it’s in my Amazon queue now.

    pm215, I’m not sure how I forgot to talk about target audiences, I’ll update the post to mention this. But in a nutshell, Zeller seems to be intended for casual reading or for use in a CS class, whereas the other three are solidly aimed at practitioners. I found that there was value in all of them even though I’ve been debugging for 30 of the 40 years I’ve been alive. As Alex says, Agans is a probably a great quick refresher for just about anyone.

  7. RobertH | March 1, 2013 at 3:37 pm | Permalink

    I’d have to recommend Bob Pease’s book “Troubleshooting Analog Circuits” because it’s also a great work on general troubleshooting thinking and techniques. But for the CS non-hardware crowd, maybe not. :-)
    http://books.google.com/books/about/Troubleshooting_Analog_Circuits.html?id=3kY4-HYLqh0C

  8. Alex Groce | March 1, 2013 at 7:11 pm | Permalink

    Ok, you guys just sold me the Phone on Fire book, too.

  9. regehr | March 5, 2013 at 8:44 am | Permalink

    Thanks RobertH, great to see that book is still in print.