Debugging the Development Process

by Steve Maguire (Microsoft Press, 1994, ISBN 1-55615-650-2)
reviewed by Brian Marick on October 18, 1996
Buy this book from fatbrain.com technical bookstore

From the introduction:
"The typical lead is usually embarking on the development of version 4.21 of an application or working on some other project that has a fairly straightforward future everybody is in basic agreement about. The typical software lead doesn't need to be a radically inspiring leader capable of getting team members to do outlandish things. The typical software lead simply needs to be effective, which is quite learnable and doesn't require anything like a personality transformation. It just requires learning the habits and strategies that have been found to work in bringing quality products to market on schedule - and without working 80-hour weeks."

This book is about adopting small, sensible strategies rather than grand schemes. As such, it should appeal to any fan of gradual process improvement. Now, many among us shy away from anything containing the word "process". Such works are often ponderous, impractical, overbearing, and evangelical. Those people will be reassured by Maguire's very first motto, on page 2:

Any work that does not result in an improved product is potentially wasted or misguided effort.

Maguire is writing for the development lead, who he believes is the servant of the product and the developers. His book describes habits of thought and action that protect the project from disruption. Two examples:

1. He spends a few minutes every day making a list of answers to the question "what can I do today that would help keep the project on track for the next few months?" Doing that means realizing you need additional hardware before it's a crisis, making sure that everyone who depends on your team's code knows that requests for new features have to be in by Monday, and so on.
2. He has a rule that every bug should be fixed as soon as it's found. That makes the project's true status more knowable. Features marked "done" on the schedule really are close to being done, not some unknown amount of debugging away. Further, this rule introduces a beneficial feedback loop. Someone who produces lots of bugs will be restricted to working on a small set of features, rather than being free to contaminate the whole product.

I like all of Maguire's suggestions, but I fear they may have this problem:

• A small crisis raises the pressure to "do something".
• That something involves setting aside some of Maguire's rules - "just for now".
• That makes them easier to set aside next time.
• Further, the "something" may bring short term relief but lead to a similar (perhaps larger) crisis later...
• ... which will take you around the cycle once more

This is exactly the way good resolutions fade away: one compromise at a time. I've seen this book in many offices, so I suspect many development leads have read it, resolved to follow these strategies, but found themselves a year later in the same morass as before. To avoid this problem, you can apply the book recursively:

• Build in feedback loops that counter the pressure to get sloppy. (I've used the way I get paid for this purpose.)
• Spend a few minutes every day thinking of how you can keep your resolutions on track.

But as important as building in countervailing pressures is avoiding the single most common reason for getting sloppy: schedule pressure. Maguire recommends aggressive but attainable schedules, on the grounds that they keep the team focused. I agree, but that only increases the need for good estimation, something hardly common in our field. The greatest flaw in this book is that it does not discuss estimation, only scheduling once you've estimated.

This book will help you with the following tasks

Click on the task name to see other works that address the same task.

Having meetings

Maguire improves them by having fewer of them, eliminating meetings when their goals can be accomplished in other ways. When they must be had, he provides some useful tips for scheduling them and running them.

Managing developers

Maguire defines the development lead's job as "ruthlessly eliminating any obstacles that keep the developers from the truly important work: improving the product".

Project planning

Maguire recommends milestone-based scheduling, in which the project is broken into small, coherent subprojects, each a couple of months long. In addition to surfacing cumulative schedule slips quickly, small milestones keep project enthusiasm high because a significant goal is always in sight.

Notes on using this book

This book is for the developer lead. Writing Solid Code, also by Steve Maguire, is directed to the individual developer. Unsurprisingly, the two books go well together. Read them both.

Gerald Weinberg's Software Quality Management, Volume 1, is rooted in the notion of feedback loops. Volume 3 describes the addictive feedback loop that often prevents small, sensible strategies from taking hold.

This book's table of contents

1. Laying the Groundwork
2. The Systematic Approach
3. Of Strategic Importance
4. Unbridled Enthusiasm
5. Scheduling Madness
6. Constant, Unceasing Improvement
7. It's All About Attitude
8. That Sinking Feeling
Epilogue: A Word on Leading
References