Krzysztof Koźmic's blog

I bought Release it! some time ago, and it was a really good book. Now Prag­matic Pro­gram­mer released a new book in their ‘do it!’ series – Debug it!, so when I got a change to snap a copy, I did, and I’m here to let you know that it is a remark­able book.

First of all, I think the title might be a lit­tle mis­lead­ing for some peo­ple. It is about debug­ging in a broader sense than most peo­ple define it. If for you debug­ging equates deal­ing with debug­ger, you won’t find much of that in this book. The book talks about debug­ging as in get­ting the bugs out of your soft­ware (and doing your best to make sure they won’t come back).

The book is divided into three parts:

The first part, which accounts for almost half of the book, talks in great detail about four stages of deal­ing with bugs in your code – repro­duc­tion, diag­nos­tics, actual fix and reflect­ing over rea­sons why the bug was there in the first place. There is not much earth shat­ter­ing here, and when read­ing this part you’ll (hope­fully) think to your­self – “yeah, I knew this” and “sure, it makes per­fect sense”. The fact that this all com­mon sense, and rules of thumb are gath­ered in one place though, and backed up by con­crete dis­cus­sion and good anec­dotes helps you orga­nize your work­flow when deal­ing with mis­be­hav­ing code. The fact that what you felt under your skin is said out loud makes you stop and real­ize there’s deeper mean­ing to all this.

Sec­ond part is rel­a­tively small, but con­cen­trates on very impor­tant topic – work­ing with peo­ple. That includes both, work­ing with QA depart­ment and users as well as work­ing with bug track­ing sys­tems. It dis­cusses what makes a good bug report, what it should con­tain, what it should not con­tain etc. This part was a rev­e­la­tion, and if I could I would make it manda­tory to read for all my clients, and peo­ple sub­mit­ting bugs to OSS projects I con­tribute to. Then it moves to prag­matic approach towards work­ing with bugs (hey, it’s a Prag­matic Book­shelf book after all). It talks about per­fec­tion­ist atti­tude of bug-free soft­ware, and work­ing with soft­ware that is rid­dled with bugs, which was inter­est­ing to read in the con­text of Tim’s post.

The final part, is a loosely con­nected group of top­ics, though it is as valu­able as the pre­vi­ous ones. It talks about spe­cial cases, like ser­vice releases, about build­ing the ideal debug­ging envi­ron­ment, which I found par­tic­u­larly inter­est­ing as this is topic close to my heart, although I would dis­agree with the author, who dis­cour­ages exten­sive use of branch­ing is source con­trol. We also get a chap­ter on how to make soft­ware easy to debug. The book ends with list of anti-patterns along with dis­cus­sion about how to rem­edy them.

I know that this book influ­enced the way I work now, and there aren’t many books I could say some­thing like this about. It dis­cusses extremely impor­tant part of soft­ware engineer’s pro­fes­sion, and does it very well. If you call your­self a prag­matic pro­gram­mer I think you should read this book.

Note, that this is a review of very early MEAP release – this is not com­plete book, and I review only 2 chap­ters that are avail­able at the time of this writing.