From Book News, Inc.
Provides a short overview of a successful software project and details a plan for software development for medium-sized client/server projects using such modern development practices as object-oriented design and programming. (Can also be adapted for projects using traditional development practices and mainframe computers.) Designed for commercial applications and business systems, the plan is not rigorous enough to support life- or safety- critical systems. Book News, Inc.®, Portland, OR


Dr. Dobb's Journal
Read the entire review of this book. Targeted at managers (from the top of organizations down through technical leads), McConnell's book provides a blueprint for a successfully managed project; the postulated development effort involves "3 to 25 team members and schedules of 3 to 18 months." At 288 pages, the book could be thinner, but it's easy enough to get through. McConnell has an engaging, conversational style, with a tinge of irreverent humor -- both of which make this book easy to approach. He uses little jargon and includes a comprehensive glossary, so nontechies should find it easy enough to follow.

ANNOTATION

This project management guide for technical leaders and managers distills practical wisdom from the author's prior publication, Rapid Development. It also includes management requirements and standards from IEEE's "Key Practices of the Capability Maturity Model, Version 1.1" and the NASA SEL``s "Recommended Approach to Software Development, Revision 3."

FROM THE PUBLISHER

This is the field guide for everyone involved in software development--especially those without formal management training. Acclaimed expert Steve McConnell maps out a proven approach to project management that you can learn and use successfully right away.

Experience Level: All

SYNOPSIS

This is the field guide for everyone involved in software development--especially those without formal management training. Acclaimed expert Steve McConnell maps out a proven approach to project management

FROM THE CRITICS

Booknews

Provides a short overview of a successful software project and details a plan for software development for medium-sized client/server projects using such modern development practices as object-oriented design and programming. (Can also be adapted for projects using traditional development practices and mainframe computers.) Designed for commercial applications and business systems, the plan is not rigorous enough to support life- or safety- critical systems. Annotation c. by Book News, Inc., Portland, Or.

Michael E. Fitzpatrick

Consider the Alternative

McConnell's latest book, Software Project Survival Guide, is a recipe for the success of any software project. He has made it easy for project managers to be effective by outlining the items needed for a software project's success in clear, tabular form and giving examples to demonstrate his concepts.

As a bonus, many of these items are online at his web site. In chapter 2, the "Survival Test (http://www.construx.com/survivalguide) sums up the important points presented in the rest of the book. I highly recommend it to everyone. It will give you valuable insight on the possible shortcomings of your own project. In chapter 7 is a "Sample Top Ten Risks List". Using this list as a guide, you'll be better able to identify risks and do contingency planning. And, of course, McConnell doesn't neglect QA plans. Chapter 9 identifies the "Recommended Quality Assurance Practices and Responsibilities for This Book's Work Products."

In a sense, this whole book is about software quality. Software project teams have little hope of delivering their products on time and in budget without ensuring quality throughout their development. McConnell reminds us many times throughout the book:

Researchers have found that an error...tends to cost 50 to 200 times as much to correct late in the project as it does...close to the point where it originally [occurred].

By software quality, I don't mean to say that this book covers only quality assurance (QA) issues. The QA phase is the final stage of a project where defects are found and corrected. Since exhaustive testing is the only way to be sure that software meets its design goals and is defect free, the best way to ensure quality is to build it into the development processes. Otherwise, QA can take enormous amounts of time. It is a major cause for the failure of software projects. In McConnell's view, such processes are the most important part of developing any software project, and they are the only way to be sure that product quality is maintained for the duration of the project.

One of the biggest hurdles that Software Project Survival Guide must overcome is that many programmers view "process" as a four-letter word. They see it as rigid, restrictive, and inefficient. What they don't realize is that they will eventually employ processes in response to situations that could be avoided if only they realized its value. They use processes reactively and may not even be aware that they are using them at all.

This book creates a valuable template for any software project manager to follow. This is especially evident if you look at the two base references McConnell cites in the preface. His interpretation of the models makes it easy for us to benefit from them. The Software Engineering Institute's (SEI) "Key Practices of the Capability Maturity Model, Version 1.1" (http://www.sei.cmu.edu) is a gold mine of hard won industry experience. NASA's Software Engineering Lab's (SEL) "Recommended Approach to Software Development, Revision 3" (http://fdd.gsfc.nasa.gov/seltext.html) describes a structured sequence of practices that may be used to implement many of the processes described in the SEI document.

You can get a good idea of McConnell's views on software project management before reading this book by visiting his web site at (http://www.construx.com/stevemcc). He has included many of the magazine articles he has written. I particularly liked "From Anarchy to Optimizing" (Software Development, July 1993). In fact, I was disappointed that he didn't include this information in his book. This article describes The SEI Process Maturity Model in understandable terms. According to the article, only 1 percent of companies use the methods necessary to reduce cost and improve the quality of their software (Note 1). This means that the ideas McConnell helps to promote are generally not well recognized.

The Software Project Survival Guide doesn't adequately address this point. There is very little discussion of the relationship between creating and using processes (chapter 3) and shipping software (chapter 4). From my experience, when processes are always neglected in the name of shipping product. For example, I was once denied a job because the boss thought I would focus too much on "process" and that it would distract me from the work. And the day before I wrote this review, a coworker told me that he prefers to "get to the work," rather than "waste time in planning a software product." This is truly a prevalent and troubling viewpoint. Personally, I enjoy the planning and design stages because they are creative stages. The implementation seems more like work and it can be frustrating work if the design and planning are hortchanged.

Also, I would have appreciated some comparison of the more common software project techniques. In my career as a consultant, I have seen many methods used to measure and control software development. Although McConnell recognizes that other management methods exist, he makes no attempt to summarize any of the methods in common use. For many programmers, this would help them understand the software project plan that he describes.

Many books on software project management are highly technical and difficult to read, like the SEI and SEL documents. Others are anecdotal, like McCarthy's Dynamics of Software Development, which I reviewed in Dr. Dobb￯﾿ﾽs Journal in August 1997. Compared to McCarthy's book, McConnell's book presents an ideal approach to project management. McCarthy's book recounts his experiences as a Microsoft project manager. His style is informal, his book is fun to read and can be read quickly, but it will soon be forgotten. When his writing becomes awkward, the information isn't very valuable anyway. In contrast, McConnell's book will be remembered for a long time. He is an experienced wordsmith and develops his ideas with clarity and purpose. Even though it is easy to read, I found myself reading it slowly. Every paragraph has something to offer the reader.