Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams Paperback – August 1, 1994
Windows 10 For Dummies Video Training
Get up to speed with Windows 10 with this video training course from For Dummies. Learn more.
Customers Who Viewed This Item Also Viewed
Top Customer Reviews
The book mainly explains the obvious (although too often ignored) practices that helps your development project: stay focused, avoid distractions, avoid interruptions, avoid wasting time, avoid unnecessary meetings (meetings are interruptions and far too often a waste of time), fix bugs early. The book has some stories to explain the above practices. But, the book has no hard facts to help you fight for the above practices in case you have a "pointy haired" boss.
In my opinion "Rapid Development" by Steve McConnel is a far better book. "Rapid development" has all the hard facts that "Debugging the development process" lacks. "Rapid development" also describes more practices and has a broader view of the development project that "Debugging the development process".
Chapter 1 talks about "laying the groundwork" -- priorities work, establish goals, coding priorites. How true this is ... how often have we started development when we are unsure of what the management wants to achieve out of it.
Some of the other strategies include having 40 hour week(hmm ... reminds me of Extreme Programming) and about the danger of having working 12 hours per day. He also spoke about ensuring personal growth in dividuals, and how it directly helps the company.
This book is written in simple english, straight to the point. To everyone doing software development, this is a must-read!!!
· Focus on project goals and priorities · Simple process changes yield big results · Attack the right problem · Features must be strategic for the product · Look ahead, don't let foreseeable problems surprise you · Effective meetings end with decisions and minimize disruptions to work · Post-mortems are effective if they answer how to fix problems · Schedules are best if milestone driven, giving the team a sense of "wins" · Grow your people, focus on immediate opportunities for feedback, avoid end of season coaching · The product is everything that's in the box · Leverage · Productivity
I liked the real-world examples, and the varied experiences cited from within the walls of a respected development organization.
In a nutshell, his advice is to 1) free up the engineers' time by reducing unnecessary paperwork, 2) eliminate any unnecessary features, 3) slip ship dates to ensure quality, and 4) increasing training for under-performing engineers. He advises against 1) adding extra engineers when the project looks to be in trouble, 2) forcing engineers to work long hours to hit ship dates, 3) schedule development activities without a clear milestone plan in mind, and 4) holding on to superstar engineers who need room to grow.
These ideas are very good, of course. It's important to keep engineers from being overworked and to keep product quality as high as possible. But there is a limit to how far Maguire's tips can take you.
Schedule slips and dropped features seem like an easy thing to do when you're just talking about it, but what can you do when the command comes down from the upper echelons of management that you must ship or die trying? Maguire does get one thing right on this count, he describes teams where a third of the engineers (the best ones, of course) quit the company after the project completes.
What happens when an engineer is severely underperfoming and is holding the team back? Continue providing that person training? Maguire's teams, luckily for him, are made up of well-trained, highly focused engineers who, given the chance, can work on a product for 8 hours a day.Read more ›
Most Recent Customer Reviews
A co-worker recommended the book so I pick up a used copy from a 3rd party vendor here on the Amazon site. Read morePublished on May 14, 2008 by jgj
This book is great if you are managing software engineers (or are one being led).
I highly recommend it!
This book makes lots of good points about the software development process. Steve's ideas ring true based on my past experience with more companies than I like to think about. Read morePublished on July 5, 2005 by J. Babcock
When I read this book, the information seemed simple and obvious. However, I also realized that there were a number of things mentioned that I wasn't doing. Read morePublished on June 14, 2004 by Philip R. Heath
This is really a very good book. I wanted to use it as a textbook for a Software Engineering class I am teaching, but now that it is out of print I felt I couldn't. Read morePublished on December 24, 2002 by Jonathan L. Conradt
This is one of the great books that i have come across on software project management. The book is not only good for project leads/managers but also for individual developers. Read morePublished on October 4, 2001 by Venkat
This book is a must-read for anyone working on software. How many times have you been on a project that was out of control? Read morePublished on June 25, 2001 by James Osborne
Overall this is a good book that is an easy quick read. All of the ideas presented though are common sense. Read morePublished on March 30, 2000 by David A. Carlson