Rapid Development

by Steve McConnell
(Microsoft Press, 1996, ISBN 1-55615-900-5)
reviewed by Brian Marick on March 22, 1997
Buy this book from fatbrain.com technical bookstore

From the preface:
"Software developers are caught on the horns of a dilemma. One horn of the dilemma is that developers are working too hard to have time to learn about effective practices that can solve most development-time problems; the other horn is that they won't get the time until they do learn more about rapid development...

The development-time problem is pervasive. Several surveys have found that about two-thirds of all projects substantially overrun their estimates (Lederer and Prasad 1992, Gibbs 1994, Standish Group 1994). The average large project misses its planned delivery date by 25 to 50 percent, and the size of the average schedule slip increases with the size of the project (Jones 1994)...

Although the slow-development problem is pervasive, some organizations are developing rapidly. Researchers have found 10-to-1 differences in productivity between companies within the same industries, and some researchers have found even greater variations (Jones 1994).

The purpose of this book is to provide the groups that are currently on the "1" side of that 10-to-1 ratio with the information they need to move toward the "10" side of the ratio. This book will help you bring your projects under control. It will help you deliver more functionality to your users in less time. You don't have to read the whole book to learn something useful; no matter what state your project is in, you will find practices that will enable you to improve its condition."

This book's main audience is project managers and development leads. Documentation leads and testing leads will benefit from certain of the general-purpose chapters, such as the one on risk management

McConnell presents a smorgasbord of software project management techniques, biased toward achieving the best possible schedule. He begins by laying the groundwork for what he calls "efficient development": avoiding classic mistakes, managing risks, and applying development fundamentals (do design before coding, use configuration management, etc.). Then he adds schedule-oriented practices that tilt the development effort toward the best schedule. This is not a "quick fix" book, though certain of the techniques are easy to apply and have immediate benefits.

In evaluating a book like this, a reviewer must ask two questions:

1. Given that no one has a long enough working life to experience all these techniques in action, has the author done a good job of winnowing out what's reasonable from what's bogus?
   
   McConnell gets good marks here. He's read everything. The book has a bias toward methodical process (as opposed to, say, James Bach's bias toward extreme flexibility), but it presents other styles fairly.
   
   I fault McConnell for using few examples from his own experience. Had he done so, I would more easily be able to sort techniques into those I trust because McConnell's personally seen them work, those I trust a bit less because McConnell's only talked to people who've seen them work, and those I'm suspicious of because McConnell probably had to infer or excavate much from the published accounts. (The software engineering literature is rotten with case studies and surveys that provide too little context.) As it is, I have to infer his experience from the text. Some chapters contain little nuggets of wisdom and tricks of the trade that make me say, "Aha! This is the writing of someone who's done exactly this." Others are more abstract, which makes me say, "This is the writing of a gifted summarizer of the literature."
   
   
2. Has the author presented the techniques such that the reader understands where they apply, where they do not apply, what limitations they have, how long it will take to achieve their benefits, and how they can be misused?
   
   McConnell does an excellent job, the best I've ever seen. For this alone I recommend the book.

Bottom line: Anyone involved in the planning of a software project should buy this book before the project begins. Skim chapters 1-4. Read chapter 5 (on Risk Management) carefully. Skim chapter 6. Read chapter 7 (Lifecycle Planning): that will help you decide what kind of project you'll have. Browse the rest of the book for relevant chapters. (The book is over 600 pages long, the writing isn't sprightly enough to sustain interest through all sections, and the organization is explicitly designed for browsing.) Continue dipping into the book throughout the project.

This book will help you with the following tasks

Click on the task name to see other works that address the same task.

Project Planning

The chapters on classic mistakes, risk management, and project lifecycle models are essential. The section on estimation is primarily top-down, using the predicted size of the software to create person-month and then calendar time estimates. If you have estimation problems (and who doesn't?), the background discussion and some of the tidbits will help, but there's no magic solution here. The major benefit of the estimation chapters is that they provide some common sense (and data) about what's not possible.

Making the ship decision

The way this decision is made depends on the lifecycle model your project follows. The right model can make the decision less traumatic.

Project recovery

There's a valuable chapter on rescuing a project that appears as if it will never finish, much less finish on time. McConnell advocates a modest (but psychologically hard) approach of dropping a few features, increasing productivity as much as you can, and slipping the schedule as needed.

Managing developers

There are chapters on motivation and teamwork, but they are rather abstract, almost anthropological. It's the sort of discussion that makes people without a feel for the human touch worse managers, rather than better, but there are some good tidbits. The discussion of different team structures is both interesting and useful, if again a bit schematic.

Discovering requirements

A brief discussion of techniques for eliciting requirements. There's a good chapter on removing requirements (requirements scrubbing, feature-set reduction), something poorly covered in other books.

Managing changes

The book contains a brief description of a change board that does feature set reduction in the middle of a project.

Architectural Design

The book contains a brief and conventional chapter on Designing for Change.

Inspecting or reviewing

McConnell gives a brief description of formal inspections.

Build management

A good description of using daily builds to reduce schedule risk.

Documentation planning and test planning

The book is mostly targeted toward software development, but the chapters on risk management, classic mistakes, motivation, teamwork, and team structure are general purpose. The discussion of lifecycle models is something technical writers and testers need to know for their planning.

Notes on using this book

McConnell's previous book, Code Complete, has the same style, but is targeted to the individual developer.

This book's table of contents

Part 1 - Efficient Development

1. Welcome to Rapid Development
2. Rapid-Development Strategy
3. Classic Mistakes
4. Software-Development Fundamentals
5. Risk Management

Part 2 - Rapid Development

6. Core Issues in Rapid Development
7. Lifecycle Planning
8. Estimation
9. Scheduling
10. Customer-Oriented Development
11. Motivation
12. Teamwork
13. Team Structure
14. Feature-Set Control
15. Productivity Tools
16. Project Recovery

Part 3 - Best Practices

17. Change Board
18. Daily Build and Smoke Test
19. Designing for Change
20. Evolutionary Delivery
21. Evolutionary Prototyping
22. Goal Setting
23. Inspections
24. Joint Application Development (JAD)
25. Lifecycle Model Selection
26. Measurement
27. Miniature Milestones
28. Outsourcing
29. Principled Negotiation
30. Productivity Environments
31. Rapid-Development Languages (RDLs)
32. Requirements Scrubbing
33. Reuse
34. Signing Up
35. Spiral Lifecycle Model
36. Staged Delivery
37. Theory-W Management
38. Throwaway Prototyping
39. Timebox Development
40. Tools Group
41. Top-10 Risks List
42. User-Interface Prototyping