Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Review of Debugging the Development Process by Steve Maguire

I had the opportunity to borrow this book from a friend, so I read it over my “currently reading” book. It’s a quick read, and the time was well spent.


As I was reading Debugging the Development Process, I realized how much agile practices evolved from solid software development experience like Steve Maguire’s. Look at the foundational practices he puts forth:



  • Any work that does not improve the product is potentially misguided

  • The lead (or PM) should eliminate any obstacles that keep developers from working on the product

  • Find out what the true goal is of any activity, then find the most efficient way to get the value of it

  • Establish coding priorities and quality bars to guide the development process

Maguire ended up fixing a lot of projects at Microsoft until the company changed its scheduling process. His methods bear significant influence on what we call agile practices today. For example, fix bugs before writing new code (Test Driven Development), continually improve the process (Scrum), shorten feedback loops (Lean Software Development), and stem process growth (all agile software development). You can easily see how Maguire’s guideline to “implement features only if they are strategic to the product” bears more than a passing resemblance to the strict prioritization of requirements inherent in most agile processes.


One thing Maguire challenges is the idea of the daily meeting. In Scrum, subsequently adapted by most agile processes, there is a short (i.e., 15 minute) meeting to report what each person did yesterday, what they are planning to do today, any problems encountered, and any ideas for improvement. Maguire said that he can get the same information from that meeting without having everyone meet. So how does the team get together to interact? He counters with they should be interacting constantly in their place of work, and if not, take the group out to lunch or something similar. Activities that have no negative connotation with them will usually result in better team interaction.


There is an entire chapter dedicated to “scheduling madness.” The key takeaways are that the PM or lead should never allow the schedule to demoralize the team, yet should be aggressive enough to keep everyone focused. The short iterations in most agile software development processes leave little time, if any, so there is no problem with focus there. Steve also suggested breaking projects into short subprojects (iterations again) and making sure each subproject has an exciting conclusion. I think the agile focus on always creating fully functional software is roughly equivalent.


There’s more to the book, with chapters covering attitudes, improvement, and how to avoid overtime (that would be my favorite!). There is almost no code in this book, but it is definitely a must-read for people that are taking on project-related duties.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

11 Responses to Review of Debugging the Development Process by Steve Maguire

  1. Jennifer Square's Blog says:
  2. Darrell says:

    Jennifer – "the book basically argues that if you read a book, attend a training class, and don’t DO something about it at work, then what’s the point?"

    There is no point, unless you are a teacher or someone who just wants to sit on a bunch of useless trivia!

  3. Darrell says:

    Jennifer, you probably know this already, but the PMP did have an IT CAQ (Certificate of Added Qualification), but they suspended the CAQ program because nobody used it. :)

    http://www.pmi.org/info/PDC_CAQSuspend.asp

  4. Jennifer says:

    Just one more thing. I may do a separate blog on my own site about this; but this book should be a text book in these PMP classes I was talking about. In fact, they should develop a certification for PMPs that is just software-project based, and make this book one of the "you must take a test on this book" requirements. I might actually enjoy working with PMPs more if they understood some of these concepts in this book.

  5. Jennifer says:

    More about Debugging. I was there in those silly status meetings with Dave and agreed with him 100% about NOT having a status on the status report. As much as managers like having status reports, not many people read anymore, so I don’t understand the point of textual status reports.

    Developers should be left out of many meetings like this as possible. It is true; things started to change for some of the project leads on our team.

    Another good book (don’t waste your time reading the whole thing, only read a few chapters) is The Knowing Doing Gap. This is why Dave is so awesome—the book basically argues that if you read a book, attend a training class, and don’t DO something about it at work, then what’s the point? If you read something and it’s a good idea, try it out…don’t just read the book or go to class. I wholeheartedly agree, and this is Dave needs to write another blog about this experience.

  6. Jennifer says:

    What a big loser. Dave read my copy of the book. If he remembers correctly, I gave him the book to read! Then he gave it back to me with about 250 stickies on all the important pages!

    All project leads/managers should be forced to read this book.

  7. Darrell says:

    Dave – you’re lucky that management changed! On an old project we had to turn in a status report on Thursday and then have a status meeting on Friday. No joking. And the meetings and reports were about why we weren’t on schedule!

  8. Dave Donaldson says:

    Almost forgot one funny anecdote: during the time I was reading this book, I was on a project where we were having status meetings to talk about everyones status report. Yes, I’m serious. I kept telling management, "You have my status, read it."

    Then they read the book. Those status meetings and status reports soon stopped.

  9. Dave Donaldson says:

    This is one of my favorite non-coding books. I read it a couple years ago and immediately showed it to a couple of project leads to read. Within a couple weeks of reading we had a serious shift in our approach to managing projects. Before reading this book, I would get in hot water a lot because I always skipped meetings that I felt I didn’t need to be at (because they kept me from actually doing work). That attitude changed with everyone around me as this book made its way through the development teams (yes, I enjoy being vindicated :-)

    I still work that way today. The cool thing is that now when I interview people or am being interviewed, I ask people (even the interviewer) if they’ve read this book. The reason: it gives me an indication on how they focus on projects.

  10. Darrell says:

    Steve – no I have not read Writing Solid Code, but it sounds like I will have to add it to the reading list now!

    I’ve noticed since I started practicing TDD that I code much more defensively now, and take more responsibility for making sure my code does what it says it is going to do.

  11. Steve Hebert says:

    Nice review, I haven’t read that book in a long time.

    Have you seen "Writing Solid Code" also by Steve Maguire? This is primarily a c/c++ book but the principles are pretty universal. Among other things he focuses on using the compiler and associated tools to locate problems as quickly as possible. He preached the ASSERT check early and often mantra very effectively. I’ve got to believe the entire focus of NUnit is right inline with his thinking.

    http://www.amazon.com/exec/obidos/tg/detail/-/1556155514/102-4988896-7766525?v=glance

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>