Posts Tagged ‘book review’

Book Review: Debugging the Development Process

Thursday, July 15th, 2010

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!

Book Review: Why is the Phone on Fire?

Monday, April 5th, 2010

That’s not the full title of the book, just the most memorable part. The full title is If I Only Changed the Software, Why is the Phone on Fire?: Embedded Debugging Methods Revealed. I pulled it off the library shelf on a whim. I want more ability to explain debugging to others, and besides, library checkouts are cheap.

It turned out to be an extremely good whim. Despite some minor issues, this book is an extremely readable introduction to how to approach debugging, with a fair bit of specific advice. It’s structured as a series of chapters about a fictional team. Each chapter is bracketed by discussion of a specific real-world bug that caused a lot of very visible trouble. Inside each chapter, the fictional team struggles to figure out a problem that turns out to be caused by similar forces. The discussion focuses on their thought patterns and realizations. The writing is nicely specific without having to include a lot of source code. Symptoms and behaviors are the main focus.

Although the title specifies embedded debugging, most of the techniques in this book can (and should!) be applied to any sort of debugging. The value in this book isn’t in the specific situations it describes, but in the approach to diagnosis and problem-solving it teaches. That said, all of the situations in this book use relatively small software systems. A book on debugging larger systems would be a good next read. The closest match I can think of is Working Effectively With Legacy Code, but that has a development focus, not a debugging focus. (I recommend it in its own right, but it’s not an obvious follow-up for this book.)

Although Why is the Phone on Fire? is generally a good resource, there were some problems with its writing. The members of the fictional team behave in racially stereotyped ways. The writing style was occasionally pedantic — I could sometimes interpret this as the old hands on the team being patronizing to the newbie, but that’s problematic too. I think these problems are overshadowed by the positive qualities of the book, but potential readers should be aware of them going in.

Overall, it’s a very good book in an underserved market niche. I’m going to buy a copy for lending purposes.