Book Review: Debug It! (Paul Butcher, Pragmatic Bookshelf)

---

Paul asked me to review this, his first book, and my comment to him was that he had
a pretty high bar to match; being of the same "series" as Release It!,
Mike Nygard's take on building software ready for production (and, in my repeatedly
stated opinion, the most important-to-read book of the decade), Debug It! had
some pretty impressive shoes to fill. Paul's comment was pretty predictable: "Thanks
for keeping the pressure to a minimum."

My copy arrived in the mail while I was at the NFJS show in Denver this past weekend,
and with a certain amount of dread and excitement, I opened the envelope and sat down
to read for a few minutes. I managed to get halfway through it before deciding I had
to post a review before I get too caught up in my next trip and forget.

Short version

Debug It! is a great resource for anyone looking to learn the science of
good debugging. It is entirely language- and platform-agnostic, preferring to focus
entirely on the process and mindset of debugging, rather than on
edge cases or command-line switches in a tool or language. Overall, the writing is
clear and straightforward without being preachy or judgmental, and is liberally annotated
with real-life case stories from both the authors' and the Pragmatic Programmers'
own history, which keeps the tone lighter and yet still proving the point of the text.
Highly recommended for the junior developers on the team; senior developers will likely
find some good tidbits in here as well.

Long version

Debug It! is an excellently-written and to-the-point description of the process
of not only identifying and fixing defects in software, but also of the attitudes
required to keep software from failing. Rather than simply tossing off old maxims
or warming them over with new terminology ("You should always verify the parameters
to your procedure calls" replaced with "You should always verify the parameters
entering a method and ensure the fields follow the invariants established in the specification"),
Paul ensures that when making a point, his prose is clear, the rationale carefully
explained, and the consequences of not following this advice are clearly spelled out.
His advice is pragmatic, and takes into account that developers can't always follow
the absolute rules we'd like to—he talks about some of his experiences with "bug
priorities" and how users pretty quickly figured out to always set the bug's
priority at the highest level in order to get developer attention, for example, and
some ways to try and address that all-too-human failing of bug-tracking systems.

It needs to be said, right from the beginning, that Debug It! will not teach
you how to use the debugging features of your favorite IDE, however. This is because
Paul (deliberately, it seems) takes a platform- and language-agnostic approach to
the book—there are no examples of how to set breakpoints in gdb, or how to attach
the Visual Studio IDE to a running Windows service, for example. This will likely
weed out those readers who are looking for "Google-able" answers to their
common debugging problems, and that's a shame, because those are probably the very
readers that need to read this book. Having said that, however, I like this agnostic
approach, because these ideas and thought processes, the ones that are entirely independent
of the language or platform, are exactly the kinds of things that senior developers
carry over with them from one platform to the next. Still, the junior developer who
picks this book up is going to still need a reference manual or the user manual for
their IDE or toolchain, and will need to practice some with both books in hand if
they want to maximize the effectiveness of what's in here.

One of the things I like most about this book is that it is liberally adorned with
real-life discussions of various scenarios the author team has experienced; the reason
I say "author team" here is because although the stories (for the most part)
remain unattributed, there are obvious references to "Dave" and "Andy",
which I assume pretty obviously refer to Dave Thomas and Andy Hunt, the Pragmatic
Programmers and the owners of Pragmatic Bookshelf. Some of the stories are humorous,
and some of them probably would be humorous if they didn't strike so close to my own
bitterly-remembered experiences. All of them do a good job of reinforcing the point,
however, thus rendering the prose more effective in communicating the idea without
getting to be too preachy or bombastic.

The book obviously intends to target a junior developer audience, because most senior
developers have already intuitively (or experientially) figured out many of the processes
described in here. But, quite frankly, I think it would be a shame for senior developers
to pass on this one; though the temptation will be to simply toss it aside and say,
"I already do all this stuff", senior developers should resist that urge
and read it through cover to cover. If nothing else, it'll help reinforce certain
ideas, bring some of the intuitive process more to light and allow us to analyze what
we do right and what we do wrong, and perhaps most importantly, give us a common backdrop
against which we can mentor junior developers in the science of debugging.

One of the chapters I like in particular, "Chapter 7: Pragmatic Zero Tolerance",
is particularly good reading for those shops that currently suffer from a deficit
of management support for writing good software. In it, Paul talks specifically about
some of the triage process about bugs ("When to fix bugs"), the mental approach
developers should have to fixing bugs ("The debugging mind-set") and how
to get started on creating good software out of bad ("How to dig yourself out
of a quality hole"). These are techniques that a senior developer can bring to
the team and implement at a grass-roots level, in many cases without management even
being aware of what's going on. (It's a sad state of affairs that we sometimes have
to work behind management's back to write good-quality code, but I know that some
developers out there are in exactly that situation, and simply saying, "Quit
and find a new job", although pithy and good for a laugh on a panel, doesn't
really offer much in the way of help. Paul doesn't take that route here, and that
alone makes this book worth reading.)

Another of the chapters that resonates well with me is the first one in Part III ("Debug
Fu"), Chapter 8, entitled "Special Cases", in which he tackles a number
of "advanced" debugging topics, such as "Patching Existing Releases"
and "Hesenbugs" (Concurrency-related bugs). I won't spoil the punchline
for you, but suffice it to say that I wish I'd had that chapter on hand to give out
to teammates on a few projects I've worked on in the past.

Overall, this book is going to be a huge win, and I think it's a worthy successor
to the Release It! reputation. Development managers and team leads should
get a copy for the junior developers on their team as a Christmas gift, but only after
the senior developers have read through it as well. (Senior devs, don't despair—at
190 pages, you can rip through this in a single night, and I can almost guarantee
that you'll learn a few ideas you can put into practice the next morning to boot.)

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.