This post originated from an RSS feed registered with .NET Buzz by Darrell Norton. Original Post: Review of Software Project Survival Guide by Steve McConnell Feed Title: Darrell Norton's Blog Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx Feed Description: Agile Software Development: Scrum, XP, et al with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Darrell Norton Latest Posts From Darrell Norton's Blog

Over my vacation I read Steve McConnell’s Software Project Survival Guide as a sort of retrospective of our recently completed project. In the book McConnell suggests a complete, somewhat minimal development process targeted at medium-sized applications, that is, non-safety-critical applications that take from 6 to 18 months to complete with a team size ranging from 3 to 25.

As I was reading the book, I had to keep checking the published date because a lot of the concepts in the book are core agile tenets. Staged delivery is one of the key concepts in McConnell’s process, and development drives the software to a releasable state at the end of each stage. Developers estimate their work several times throughout the process, when the requirements are roughed out, when they are detailed, and at the beginning of each new stage (iterative development with constant reevaluation). The user manual is the requirements document except for calculation or non-UI intensive parts of the application (reduction in documentation). There is even a nod given to the Peopleware aspects of software development, like ensuring that developers have work environments conducive to productivity, or make the schedule with the understanding of extremely low productivity. Or getting the users involved early and often and making them a key part of the development process (user involvement and a developer focus). Sounds pretty agile to me!

Perhaps the part I liked best was McConnell’s views on process. Development processes are not bad in and of themselves. They are bad when misapplied, either with too little or too much process. All process slows down development work, but the huge gains in project visibility far outweigh the minor gains in programming efficiency. It would be faster in XP not to have to bring the software to a releasable state every 1-3 weeks, but the fact that you deliver working software into the hands of the project’s stakeholders is far more important. So the tradeoff should be made when the gains outweigh the costs.

The only part where Steve veers off course, in my opinion, is in stipulating that requirements should be 80 percent complete at the detailed level before starting architectural design. Even the Rational Unified Process suggests that only a representative 20 percent of the requirements need to be detailed, with the remaining 80 percent roughed out enough to know that there is nothing severely wrong with the architecture.

The book was an easy read. I never spent too long on a chapter and everything was presented in an approachable manner. There are graphs or pictures or diagrams on most pages to illustrate the main points. If you are new to project management, this book is a great start. If you’re a veteran, read it before your next project to pick up some important tips on improving your process.