Unlike the previous book, and unlike its title implies, this book is not about technical debugging at all. Rather, it’s about people skills and systems of people.
This book is clearly aimed at new and newish managers. It presents, argues for, and teaches a variety of human factors skills that relate to managing a small group of developers. Despite that, I think it’s useful to a wide variety of people. Most of the focus is on not letting inertia / denial / other people / conflict-avoidance make your decisions for you. It can be read like an engineer’s self-help book: action A causes bad result B via mechanism C; alternative action A’ prevents mechanism C and furthermore encourages good result D through mechanism E. There’s no coddling, but there’s no attacking, either. That said, I think it would be a dandy resource for its target audience.
Debugging the Development Process deals explicitly with subtle influences and with the fact that systems of people are not predictable by the sum of their parts. That’s both helpful and rare. I think systems and subtleties are more important to software folks than clean bite-sized absolutes, and it frustrates me that I can’t convince more of my industry.
As a pleasure read, this book also scores highly. Maguire’s writing style is unusually easy and enjoyable to read for a technical author. Like his earlier book, Writing Solid Code, Debugging was information-dense without being word-dense. I’m sad that he’s only written two books, both of them in the nineties — I’d like to see what he’d produce if he continued to write.
Perhaps the biggest flaw in this book is its age. It was published in 1994. While social systems don’t age as quickly or as badly as technical systems do (anyone want to buy my copy of Java 1.1 in a Nutshell?), there have still been useful advances in the field of software management in the last decade and a half. Much of the advice Maguire gives would still be useful for people in self-organizing teams, but it would have to be adapted from his presentation to suit. Similarly, he’s assuming a certain model of scheduling-up-front that, while it is flexible, is compatible with the incremental micro-scheduling practiced by many agile projects.
Overall, a helpful and enjoyable book, and a quick read — check it out!