Some things never go out of style, like the advice Steve Maguire dishes out in </i>Debugging the Development Process<i></i>
A man is not finished when he's defeated. He's finished when he quits.
- By Mike Gunderloy
- May 01, 2004
— Richard M. Nixon
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.
| Want to read more of Mike's work? Sign
up for the monthly Developer Central e-newsletter,
including product reviews, links to web content, and more,
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
- 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 MikeG1@larkfarm.com.
I'll use the most interesting comments in a future issue of Developer