What do you think?
Rate this book
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
In Debugging the Development Process, Maguire describes the sometimes controversial but always effective practices that enabled his software teams at Microsoft to develop high-quality software - on schedule. With the refreshing candor reviewers admired in Writing Solid Code, Maguire talks about what did and what didn't work at Microsoft and tells you how to energize software teams to work effectively - and to enjoy their work; why you might want to kick your star programmer off your team; how to avoid corporate snares and overblown corporate processes; which tiny changes produce major results; how to deliver on schedule and without overwork; how to pull twice the value out of everything you do; how to get your team going on a creative roll; and how to raise the average programmer level at your company.
183 pages, Paperback
First published August 1, 1994
4 people are currently reading
330 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 12 of 12 reviews
January 28, 2021
Actually I'm supprised that the book is still relevant 25 years after being published. Software development world hasn't changed that much. Probably there are newer books taking agile approach for granted, but if you have occasion read this one.
May 13, 2015
I read this book entirely on flights from Burbank to San Jose, and it was great in that every chapter has a simple, actionable item which will make workflow in your group more efficient. I've seen some criticism of the book in that it's too simplistic. While it's true that many of the tools are simple, it's worth asking yourself:
* When is the last time you wrote down clear goals for a project or road map and shared them with your team?
* Do you immediately schedule bug fixes as bugs are discovered?
* When you have a team member who is essential to a project, do you do everything you can to get them out of that role?
These things are all simple in retrospect, but many times they are overlooked in the day-to-day. This book is a great reminder to actively pursue these things, and it will likely have a tool or two that you hadn't thought of.
* When is the last time you wrote down clear goals for a project or road map and shared them with your team?
* Do you immediately schedule bug fixes as bugs are discovered?
* When you have a team member who is essential to a project, do you do everything you can to get them out of that role?
These things are all simple in retrospect, but many times they are overlooked in the day-to-day. This book is a great reminder to actively pursue these things, and it will likely have a tool or two that you hadn't thought of.
September 22, 2012
Useful book. It's a look at the more managerial and project management aspects of the Product Manager role.
While the contents of the book seem to highlight the role of an engineering manager or lead. It's filled with a lot of useful tidbits and best practices.
The underlying premise: "any work that does not result in an improved product is potentially wasted or misguided effort"
This potent theme carries through the book and results in a breezy read with a valuable approach that, while a bit dated still provides lessons for the modern engineering process.
While the contents of the book seem to highlight the role of an engineering manager or lead. It's filled with a lot of useful tidbits and best practices.
The underlying premise: "any work that does not result in an improved product is potentially wasted or misguided effort"
This potent theme carries through the book and results in a breezy read with a valuable approach that, while a bit dated still provides lessons for the modern engineering process.
February 17, 2019
Since Maguire almost completely avoids language and tool specifics, this book is still highly useful. While I was at best an average project manager, since I did read up on the subject, I was able to function. This book is pre-agile development, so there's a few tricks missing, but still a great read. If I ran a software company, I'd make it mandatory reading.
June 22, 2016
Even though this book is from the 90s, the advice is still relevant today. Excellent knowledge for all team leads. And even anti-MS people should still read it; even though it's an MS Press book, the advice is not specific to MS, but is symptomatic of all teams larger than 1.
August 17, 2022
I could see a few references that linked me to the extreme program book. Even though, I would bet that XP used some ideas from this book because it was published afterwards, there are some
key takeaways that is worth to any developer.
Besides that, some tips that are shared more recently in the pragmatic programmer 20th edition is also present in this book.
Despite of the examples being used are from Microsoft, the ideas shared can be expanded to other companies/projects.
All in all, it is nice to see the trend and evolution based on those publications.
key takeaways that is worth to any developer.
Besides that, some tips that are shared more recently in the pragmatic programmer 20th edition is also present in this book.
Despite of the examples being used are from Microsoft, the ideas shared can be expanded to other companies/projects.
All in all, it is nice to see the trend and evolution based on those publications.
December 8, 2021
雖然大部分的觀點現在已經有很多自我成長書會提，例如保留大塊專注時間，只拿早上剛開始的時間、中午的午休時間、下班前來處理雜事、回email或是開重要的會議，請教別人時要先提出自己的觀點而不是當伸手牌，但這本書還是有些值得參考的地方，包括
• 學習要專注於能夠帶著走的能力/專案
• 學習能夠立即應用的技能（個人成長+可以對公司產生貢獻）
• 多寫能造福整個產品的程式，而非用一次就丟了或是只能給特定小組用的
• 有做得不好的地方就制定目標，立刻改進（例如採取自動除錯方式），不要等到年度考核才在挑毛病
• 有問題發生時，問「未來如何避免」，而不是「為什麼做錯」，這兩個問題獲得的答案截然不同
• 發現問題就立刻記錄，誰幫你的、學到什麼、未來如何改善
• 不是什麼事情都非得要開會才能解決，有時候簡短的訊息(text message)就可以達到效果
• 會議一定要得到結論，不然以後也不會有「比較不忙，能夠好好思考問題」的時候
• 合理壓力與時限，而不是「達不到的 deadline」，增長工時只會讓員工開始在公司處理他們的雜事（因為回家也沒時間）
• 學習要專注於能夠帶著走的能力/專案
• 學習能夠立即應用的技能（個人成長+可以對公司產生貢獻）
• 多寫能造福整個產品的程式，而非用一次就丟了或是只能給特定小組用的
• 有做得不好的地方就制定目標，立刻改進（例如採取自動除錯方式），不要等到年度考核才在挑毛病
• 有問題發生時，問「未來如何避免」，而不是「為什麼做錯」，這兩個問題獲得的答案截然不同
• 發現問題就立刻記錄，誰幫你的、學到什麼、未來如何改善
• 不是什麼事情都非得要開會才能解決，有時候簡短的訊息(text message)就可以達到效果
• 會議一定要得到結論，不然以後也不會有「比較不忙，能夠好好思考問題」的時候
• 合理壓力與時限，而不是「達不到的 deadline」，增長工時只會讓員工開始在公司處理他們的雜事（因為回家也沒時間）
This entire review has been hidden because of spoilers.
February 10, 2023
I’m giving this five stars for the impact it has had on my thinking over the years. I read it several times in the 90s and referenced it often in my work leading projects. This was my first time I’ve looked at it in over a decade (or two?) but I quickly recognized many approaches that are still part of my practice today.
January 10, 2017
still relevant in 2017.
November 27, 2008
started yr.it's going fine....
but tooooo much examplex from Microsoft....
but tooooo much examplex from Microsoft....
August 6, 2011
I frequently refer to the section titled " Know Your Coding Priorities"
Read
October 11, 2018Read this book several times, in the early 2000's. Very useful.
Displaying 1 - 12 of 12 reviews