Review: Software Project Survival Guide

In a truimphant sophmore return, Jason Bennett has sent us in a review of Software Project Survival Guide. Part of ongoing series of books reviwed by Jason, the goal is to walk through a number of valuable software engineering books. For the full scoop, check below.

Software Project Survival Guide
author	Steve McConnell
pages
publisher	Microsoft Press
rating	9/10
reviewer	Jason Bennett
ISBN	1-57231-621-7
summary

Steve gives a good once-over of the software development process, and backs it up with good examples and on-line documentation.

Background

This being the second review in my series of software engineering books (process and management being key components of said concept), I thought it would be good to give an overview of where we are, and where we're going. Last week, we looked at Frederick Brooks' Mythical Man-Month , the seminal classic of software management. This week, we'll be looking at the latest book by a new classic author, Steve McConnell. Now, I might as well say right upfront that Steve is a Microsoftie (at least part-time). You can take that as praise or criticism, but it's truth nonetheless. Fortunately, Steve is above idol worship, and thus his books are quite palatable, even if you have to support the Evil Empire in the process. No matter who he consults for, however, Steve knows what he's talking about. In the end, that's what matters. We'll be staying in Steve country for this week and next (his Code Complete is next), after which we'll move on. For now, however, enjoy this review/summary of Software Project Survival Guide.

What's the book about?

To a large extent, this book is the culmination of many years of writing on Steve's part. His previous books are Code Complete, which focuses on the details of writing code well, and Rapid Development, which focuses on the software lifecycle, with some management thrown in for good measure. Now, with Software Project Survival Guide, Steve has written a quick-pass tutorial on how to deal with getting a program out the door. One major focus of this book is on process, that is following the steps of development closely to catch problems as early as possible. Echoing a sentiment expressed by Brooks, Steve points out that the earlier a problem is caught, the cheaper it is to fix. It's dang easier to erase a line on a whiteboard than to rip out multiple modules/objects full of code and correct them (a lesson which my project at work is currently learning).

The book is divided into four major parts:

1. The Survival Mind-Set
2. Survival Preparations
3. Succeeding by Stages
4. Mission Accomplished

The first part addresses the underlying concepts of the book (process, finding problems early, what a successful project looks like, etc), giving the reader an understanding of what it means to properly take a project through the valley of the shadow of failure. Steve also first mentions the concept of "staged delivery" in this part, something he will harp on throughout the book. Basically, staged delivery is how most open-source projects run: having multiple release dates with integral increases in functionality. For vertical or internal applications, however, this is a rarity. When software is driven to a releasable stage multiple times, it establishes the exact state of the software, allowing for better schedule estimation and allows the user to obtain a minimal, but possibly critically functional, piece of software early. Staged delivery differs from multiple versions released over time in that the final staged delivery fulfills one set of requirements stated at the beginning, while multiple versions will each have a unique set of requirements (which will typically bloat for every further release).

Part II addresses the initial, planning phases of a project, before actual detailed work is done. This includes oversight boards (of varying size, just as long as someone is reviewing the decisions), effective configuration management, risk analysis, and scheduling. Requirements are also done at this point, an architecture crafted, and QA/QC brought on board. At this point, everyone who will be involved should know what is going on, and all planning and infrastructure should be in place. Unfortunately, this stage has a tendency to drag on, as people waffle over who will do what, and what exactly will be done. My project in particular experienced some serious delays in this area, as the customers were incapable or unwilling to tell us what they needed, and when they needed it, beyond "everything, in a month." We finally got past this point, but not without wasting way too much time.

Part III digs into the meat of the process -- keeping on track while the software is being written. Brooks addresses this part of the process in MMM with his famous quote, "More programming projects have gone awry for lack of calendar time than for all other causes combined." The man speaks truth. Steve takes the project through stage planning, detailed design, construction, testing and release. These steps will then be repeated for each stage of the project, until all stages are completed. As discussed earlier, this will allow maximum delivery in a minimum time, especially of critical features. Steve also emphasizes "miniature milestones" to better gauge where the project is. There's a true saying that "90% of the project is done 90% of the time." Of course, what that really means is that no one really ever knows how much of the project is completed. However, setting small, concrete milestones all along the timeline will allow an excellent gauge of where the project is. "How does a project get to be a year late? One day at a time. (Brooks)"

Part IV discusses the project aftermath, especially learning from the project. This is a short part, and mainly emphasizes archiving all documentation and reviewing what went right and what went wrong. Steve also offers a nice list of project management resources, including other books and web sites.

What's Good?

Steve McConnell is a proven author, and as such does not disappoint. The chapters are clear and concise, with excellent checklists at the end of each. He also has an entire website devoted to supporting the book. He steps through the process methodically, making sure all parts are covered. For those of you interested in the SEI's CMM practices, Steve has drawn heavily from them for this book. My understanding is that Steve is not wedded to the model itself, although he certainly sees it as an excellent step forward. In fact, following the recommendations of this book will definitely bring a project closer to level 2 compliance.

What's Bad?

Well, if I thought the book wasn't useful, I wouldn't have reviewed it. :-) Anyway, the book does not have any glaring flaws. I think Steve tends to emphasize organizations that need five member change boards over those where the board is likely to be the manager (which is probably most organizations). If, however, you can adapt his ideas to your situation, you and your project will benefit.

What's In It For Us?

Once again, where does Open Source come into this? I'm going to end up repeating myself somewhat from last week, but I am firmly convinced that open source projects need more process and structure. The software community has managed to survive for forty years with little process, and open source has done the same for twenty. Now, however, that chapter must end. We need increased productivity and better organization to be truly effective. We need written requirements to keep the projects on track and stop the waste of time and effort that non-required code brings. We need solid design (and detailed design) to keep everyone on the same page. We already do staged delivery (to some extent), but we need to pre-document when and how this will happen, instead of putting out a release when we feel like it. Too many projects wander off into oblivion because of gold plating or lack of vision and purpose. The better we can focus our passions and efforts, the closer to victory we will come.

Purchase the book over at Amazon.

• Table of Contents

• Acknowledgements
• Preliminary Survival Briefing

1. The Survival Mind-Set
   1. Welcome to Software Project Survival Training
   2. Software Project Survival Test
   3. Survival Concepts
   4. Survival Skills
   5. The Successful Project at a Glance
2. Survival Preparations
   1. Hitting a Moving Target
   2. Preliminary Planning
   3. Requirements Development
   4. Quality Assurance
   5. Architecture
   6. Final Preparations
3. Succeeding by Stages
   1. Beginning-of-Stage Planning
   2. Detailed Design
   3. Construction
   4. System Testing
   5. Software Release
   6. End-of-Stage Wrap-Up
4. Mission Accomplished
   1. Project History
   2. Survival Crib Notes

• Epilogue
• Notes
• Glossary
• Index