Classic (De)Bug

Some things never go out of style, like the advice Steve Maguire dishes out in </i>Debugging the Development Process<i></i>

• By Mike Gunderloy
• 05/01/2004

In 1994, Microsoft was selling MS-DOS 6.22, had just released Windows NT 3.5, and had announced the forthcoming "Chicago" (later known as Windows 95) beta. Meanwhile, Steve Maguire, author of Writing Solid Code (Microsoft Press, May 1993)and an experienced Microsoft Program Manager, was releasing his second book, Debugging the Development Process (Microsoft Press, April 1994). Ten years later, I thought it might be fun to look back at this book and see how it fits for today's developers.

The Market Speaks
Ten years later, MS-DOS 6.22 and Windows NT 3.5 are nowhere to be found, but you can still hop over to Amazon and order a copy of the book. Clearly, at least some readers are finding value here. With the book being directed specifically at project leads (the subtitle is "Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams"), I suspect it actually sells to developers as well. I can see three reasons for this. First, developers will know Maguire from his earlier book on good coding practices. Second, as he points out in this book, project leads tend to come from the ranks of developers, and if you wait until you're promoted to think about the job it's too late. Third, this is just a good read; it's light and funny in spots and has plenty of war stories from within Microsoft.

In fact, even if you don't intend to ever run a software development team, you might buy it for the war stories. There's a certain pleasure to be had from reading about some particularly stupid decision and then thinking about how badly those idiots on the Word team screwed up. "It won't be like that in my company," you can vow, as you dream about the day that you too will have forty billion dollars in the bank. Of course, that's the point: Reading this book is designed to help you learn from expensive mistakes that others have made.

Basics First
Maguire starts by considering some of the basics required to produce good software on a fixed schedule. It doesn't take him long to get to an important rule that is too often overlooked: "Any work that does not result in an improved product is potentially wasted or misguided effort." One of the big jobs of the project lead is to run interference for the actual developers, protecting them from travel reports and stupid meetings and all the time-consuming trivia that any good bureaucracy will manufacture for its workers. The truly good manager also recognizes his own tendency to create waste heat in the form of excess process, and will fight against that just as hard.

Also on the basics, he talks about setting up simple systems to keep a project on track, both in the short term and in the long term. For example, if you start each day by asking what you can do to help keep the project on track for the next few months, you're much less likely to be blindsided by something in the future.

Scheduling and Slipping
Of course, managing the schedule is a big part of the project lead's job, and it comes in for a big share of the attention here. Maguire is a fan of not working people to death, believing that an 80-hour week probably just has more non-work hours in it than a 40-hour one. He discusses the necessity to push back when management or marketing or other teams want unrealistic amounts of work, and emphasizes the need to protect your developers from such nonsense. Of course, scheduling by milestones also comes in for review here; we had less experience in such things a decade ago, which is why the notion of breaking a large project down into doable tasks can be presented as somewhat of a novelty.

Of course, projects do slip (well, not all of them, but it's a good first assumption), and Maguire digs into the reasons for this and the way in which they can be combated. One thing he recommends against is promoting an attitude of slip hysteria; it's no fun to work on a project where you are told every single day just how far behind you are. Instead, he suggests strategies for getting the schedule back under control. These focus on making sure the workload is reasonable, removing the nonsense from the developers' working hours, and restraining them from pulling all-nighters. He claims to have used these techniques successfully as a sort of roving troubleshooter within Microsoft and has plenty of tales to tell.

I've got to add a caveat of my own to this rosy picture, though: When I was subcontracting for Microsoft, a few years after this book came out, death-march schedules, slip hysteria, and overnight coding were still very much in evidence. Perhaps I just didn't have the good fortune to work with any of the teams that Maguire trained.

Shooting Yourself in the Foot
One of the most important chapters here is about dumb attitudes that developers have (Maguire, more politely, calls them "buggy attitudes"). You've likely run into at least a few of these:

• Code that compiles must be correct
• This code is so obvious that I don't need to test it
• Writing the right code will take too much time
• That can't be done in code!
• It's good enough for the end users
• It's better to ship a lousy feature than to wait for the time to do it right
• The users will understand why we ignored their requests
• It's OK to skimp on unimportant parts of the product
• I don't have time to write for reuse

The nice thing is that Maguire discusses each of these with concrete examples, and walks through how he deals with them. This is a good start at a manual for project leads who need to hold design and performance reviews. Even if you're not planning to move into management, you might end up questioning some of your own habits by thinking about how you'd fare in such a review.

A Few Flaws
Of course, no book is perfect. This one is a bit dated in spots, as you'd expect from a decade-old software book. For example, the notion of a "visual freeze" date (the date when screenshots are final so that the printed manual can be published) mostly seems quaint these days. And the note about how important e-mail is within Microsoft seems a bit redundant in 2004; these days we're more likely to want to know how to get rid of e-mail than to depend on it (though the advice about not being interrupt-driven every time a message arrives is still good).

Overall, though, I still like this book. I tend to haul it off the shelf and dip into it about once a year, whether or not I'm currently managing a development team. I doubt that I'm as good a manager as Maguire; it's not been my primary focus. But I know that I'm better at it than I would have been without this book, which means that buying a copy was a good investment for me.

Got project lead war stories of your own? Amused by the very thought of best practices coming out of Microsoft? You can get hold of me at [email protected]. I'll use the most interesting comments in a future issue of Developer Central.