Back to TOCBook Review


The Software Project Survival Guide

reviewed by Dave Hamilton


Title: The Software Project Survival Guide
Author: Steve McConnell
Publisher: Microsoft Press, 1997
Pages: 250
Price: $24.99
ISBN: 1-57231-621-7

Click here for the cover

The Software Project Survival Guide is Steve McConnell's third book on the process of writing software. While the first two (Code Complete: A Practical Handbook of Software Construction and Rapid Development: Taming Wild Software Schedules) focused on the best development practices at Microsoft, this book is a series of checklists which are immediately useful in determining where you are in the project life cycle and where you need to be. The checklists are the primary focus of the book; the text explains the importance of each checklist in the software development life cycle.

I found the chapters and checklists so useful that when I started a new software project recently, I used the lists to lay out the development plan on our intranet. McConnell makes all the material available on his website (http://www.construx.com/survivalguide/), making it easy to adopt what you read into your work. We set up our web pages by modifying his lists. Just doing this much was an excellent way to think through the steps and requirements our project would need. McConnell's plan is available as an MSProject file, and that gave me a big head start. When combined with our internal metrics this made the first draft of our project schedule a one-day affair.

At first all the detail in the checklists will seem like overkill. But as you read this book, it becomes clear that each step listed is actually performed in most software projects. Mostly, however, these steps are performed unconsciously and are never documented. By making all of the little steps available to your entire team it's easier to build the shared vision needed to successfully get your project done on time and within budget. By using these checklists you insure that the little steps are taken in order. Using methods from one project to the next can help you develop a software development quality plan that is reproducible.

The text of this book is written to support the checklists instead of the usual reverse. The importance of these checklists is evident in the way McConnell describes writing a mission statement. He details what makes for a useful statement, a statement that defines the project not just to the team but also to external decision makers. McConnell steps through each small piece of each stage of the development process, explaining its benefits and pitfalls. He details both the usual waterfall processes as well as staged delivery plans.

This book begins with a survival test to let you measure where your current project stands and its chances of success or failure. You answer a series of question such as "Does the project have a detailed, written specification of what the software is to do?" and "Does everyone work well together?" You then assign points to your response. Your total points give you a measure of your chances of success. By periodically answering these questions throughout your project you can also be alerted to where project risk is gathering. This book is solid in the area of risk analysis with respect to why projects succeed and fail, and how you should track the risk factors that change weekly during the project.

McConnell proceeds to cover planning, scheduling, determining requirements, and defining the scope of the project. His checklist methods allow you to develop a change-control method that keeps you focused on the task ahead.

This book is short on the coding step, where most of us spend our time. It focuses is on the process, not the techniques. Thus, this book was apparently written for project managers and lead programmers. The chapter on construction is aimed at the techniques of source-code control, describing Microsoft's processes of daily builds and smoke testing. McConnell's other books are heavy in this area. He advocates the daily builds as important steps in both software quality control and in making each team member produce something every day.

McConnell gives only cursory coverage to the processes of system testing, and this is probably an area that needs more. Many projects end up in a death march, with programmers coding up to the ship date. A good topic for McConnell to consider in the future is the tradeoff between system testing and the pressure to ship. Even so, I am going to stick with his checklist almost verbatim in my new project, as it breaks the ship decision into pieces and assigns each piece to an individual or team. I am also going to use his release sign-off forms to remind those who push release of their involvement.

McConnell does a good job detailing the postmortem steps. In many businesses, development project data gets lost, and historical records aren't available as guidelines for the next project. You need to plan to collect metrics throughout the schedule so that your next project plan can be even more accurate.

The book ends with the NASA key guidelines and the NASA software engineering lab's checklist for success. Like the book's first survival checklist, the final one also makes a good periodic review to reevaluate where you are headed.

I highly recommend the Software Project Survival Guide. Steve McConnell is recognized as a leader in defining software development's "best practices." Just the time you save by using his checklists to organize your own plan makes it easy to justify the book's price. It's better to use the book this way than as a general read. If you are considering this for light airplane reading, you will find the checklists and explanatory text dry. It lacks the Microsoft anecdotes found in the other two books from which it was derived. Each of the two earlier books are better if you're just into reading about software engineering. On the other hand, if you're actually doing a new project, I think that integrating McConnell's survival checklists into your project is an excellent way to go. And if you are now stuck in a project that is not going right, this book will make an excellent rescue planner. o

Dave Hamilton is a C/C++ lead working for Professional Business Services, a Medical Software company in Lincoln, NE. PBS writes C code on SCO Unix and the user interface in Visual C++ under Windows NT. Dave coauthored Programming Windows NT 4.0 Unleashed (SAMS) with Mickey Williams, and has contributed to SQL Server 6.5 Unleashed (SAMS) and Visual C++ Construction Set (WROX Press).