Debugging the Development Process
12:29pm MST, 24 Jun 2002

A while ago I got an awesome deal on a book by an author I recognized: it was Debugging the Development Process by Steven Maguire. I learned some lessons with this book, and one of them wasn't what you'd expect.

Maguire's book is a companion or sequel to his popular but debated book, Writing Solid Code.

I lucked out. I saw Debugging the Development Process for a few bucks at a local computer book store. I recognized the author and I was in a mood to buy a book on software engineering, so I went for it.

One of the things that I like about this book, which is really what makes most books of this type useful, is that he challenges common assumptions and then backs up his points. It's the second part that I found strong in this book.

Most of the useful advice and experience in this book is about organizing teams and meetings. He debunks a lot of small-thinking attitudes in favour of a more strategic approach that favours what's best for the whole company in the long term. One example is learning to say no to requests from other teams--recognizing when a request can be fulfilled and when it can't or shouldn't be. The ruckus that refusing a request might cause is nothing compared to what can happen three months later when the whole project is behind schedule and you finally have to admit you can't fulfill the request.

A similarly strategic approach he advocates is to encourage your programmers to move on from a task, or even from your project, when they have no more to learn from it. He encourages you to help the company by raising the skill level and broadening the range of its programmers.

The book covers a lot of practical examples of the Peopleware methodology. He explains how a team lead can better accomplish the role of removing the obstacles to the team's progress. He advocates removing status reports and talks about how to ensure that meetings are actually productive--meaning that your meetings end in decisions, not plans to have another meeting.

The last thing this book taught me, though, was once again not to judge a book by its cover--or in this case, its price. I realized that despite all I learned from the book, I had tended not to value it because it was a bargain. It wasn't until I realized how often I was using Maguire's principles in organizing projects or meetings that I started to recognize the book's value. Finally I did a Google search for reviews, and discovered that I wasn't the only one who found the book insightful.

It's a marketing principle that we shouldn't forget for ourselves: people have a tendency to value things based on their cost, rather than price things at their value. Something to work on.

Back to Byroniverse