Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996. 660 pages. Retail price: $35. ISBN: 1-55615-900-5. Available from Microsoft Press 1-800-MS-PRESS (1-800-677-7377). Buy Rapid Development from Amazon.com.

Preface 

Software developers are caught on the horns of a dilemma. Practices exist today to solve most development-time problems, but developers are working too hard to have time to learn about these effective practices. One horn of the dilemma is that developers don't currently have time to learn more about rapid development; the other horn is that they won't get the time until they do learn more about rapid development.

Other problems in our industry can wait. It's hard to justify taking time to learn more about quality when you're under intense schedule pressure just to "get the software out the door." It's hard to learn more about usability when you've worked 20 days in a row and haven't had time to see a movie, go shopping, work out, read the paper, mow your lawn, or play with your kids. Until we as an industry learn to manage our schedules and free up time for developers and managers to learn more about their professions, we will never have enough time to put the rest of our house in order.

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). Year after year, development-speed issues have appeared at the tops of lists of the most critical issues facing the software-development community (Symons 1991).

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 (Jones 1994), and some researchers have found even greater variations (Rubin and Yourdon 1995).

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 to bring your projects under control. It will help you to 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 be able to find practices that can help you improve its condition.

Who Should Read This Book?

Slow development affects everyone involved with software development including developers, managers, clients, and end-users-even their families and friends. Each of these groups has a stake in solving the slow development problem, and there is something in this book for each of them.

This book is intended to help developers and managers know what's possible, to help managers and clients know what's realistic, and to serve as an avenue of communication between developers, managers, and clients so that they can tailor the best possible approach to meet their schedule, cost, quality, and other goals.

Technical Leads

This book is written primarily with technical leads or team leads in mind. You usually bear primary responsibility for increasing the speed of software development, and this book explains how to do that. It also describes the development speed limits so that you will have a firm foundation for distinguishing between realistic improvement programs and wishful-thinking fantasies.

Some of the practices this book describes are wholly technical. As a technical lead, you should have no problem implementing those. Other practices are more management oriented, and you might wonder why they are included here. In writing the book, I have made the simplifying assumption that you are Technical Super Lead-faster than a speeding hacker; more powerful than a loco-manager; able to leap both technical problems and management problems in a single bound. That is somewhat unrealistic, I know, but it saves both of us from the distraction of my constantly saying, "If you're a manager, do this and if you're a developer, do that." Moreover, assuming that technical leads are responsible for both technical and management practices is not as far-fetched as it might sound. Technical leads are often called upon to make recommendations to upper management about technically oriented management issues, and this book will help prepare you to do that.

Individual Programmers

Many software projects are run by individual programmers or self-managed teams, and that puts individual technical participants into de facto technical-lead roles. If you're in that role, this book will help you improve your development speed for the same reasons that it will help bona fide technical leads.

Managers

Managers sometimes think that achieving rapid software development is primarily a technical job. If you're a manager, however, you can usually do as much to improve development speed as your developers can. This book describes many management-level rapid-development practices. Of course, you can also read the technically oriented practices to understand what your developers can do at their level.

Key Benefits of This Book

I conceived of this book as a Common Sense for software developers. Like Thomas Paine's original Common Sense, which laid out in pragmatic terms why America should secede from Mother England, this book lays out in pragmatic terms why many of our most common views about rapid development are fundamentally broken. These are the times that try developers' souls, and, for that reason, this book advocates its own small revolution in software-development practices.

My view of software development is that software projects can be optimized for any of several goals-lowest defect rate, fastest execution speed, greatest user acceptance, best maintainability, lowest cost, or shortest development schedule. Part of an engineering approach to software is to balance tradeoffs: Can you optimize for development time by cutting quality? By cutting usability? By requiring developers to work overtime? When crunch time comes, how much schedule reduction can you ultimately achieve? This book helps to answer those key tradeoff questions and others.

Improved development speed. You can use the strategy and best practices described in this book to achieve the maximum possible development speed in your specific circumstances. Over time, most people can realize dramatic improvements in development speed by applying the strategies and practices described in this book. Some best practices won't work on some kinds of projects, but for virtually any kind of project, you'll find other best practices that will. Depending on your circumstances, "maximum development speed" might not be as fast as you'd like, but you'll never be completely out of luck just because you can't use a rapid-development language, are maintaining legacy code, or work in a noisy, unproductive environment.

Rapid-development slant on traditional topics. Some of the practices described in this book aren't typically thought of as rapid development practices. Practices such as risk management, software development fundamentals, and lifecycle planning are more commonly thought of as "good software development practices" than as rapid-development methodologies. But these practices have profound development-speed implications that in many cases dwarf those of the so-called rapid-development methods. This book puts the development-speed benefits of these practices into context with other practices.

Practical focus. To some people, "practical" means "code," and to those people, I have to admit that this book might not seem very practical. I've avoided code-focused practices for two reasons. First, I've already written 800 pages about effective coding practices in Code Complete (Microsoft Press, 1993). I don't have much more to say about them. Second, it turns out that many of the critical insights about rapid development are not code-focused; they're strategic and philosophical. Sometimes, there is nothing more practical than a good theory.

Quick-reading organization. I've done all I can to present this book's rapid-development information in the most practical way that I know how. The first 400 pages of the book describe a strategy and philosophy of rapid development. About 50 pages of case studies are integrated into that discussion so that you can see how the strategy and philosophy play out in practice. In case you don't like case studies, they've been formatted so that you can easily skip them. The second half of the book consists of a set of rapid-development best practices. The practices are described in quick-reference format so that you can skim to find the practices that will work the best on your projects. The book describes how to use each practice, how much schedule reduction to expect, and what risks to watch out for.

The book also makes extensive use of marginal icons and text to help you quickly find additional information related to the topic you're reading about, avoid classic mistakes, zero in on best practices, and find quantitative support for many of the claims made in this book.

A new way to think about the topic of rapid development. In no other area of software development has there been as much disinformation as in the area of rapid development. Nearly useless development practices have been relentless hyped as "rapid-development practices," which has caused many developers to become cynical about claims made for any development practices whatsoever. Other practices are genuinely useful, but they have been hyped so far beyond their real capabilities that they too have contributed to developers' cynicism.

Each tool vendor, each methodology vendor, wants to convince you that their new silver bullet will be the answer to your development needs. In no other software area do you have to work as hard to separate the wheat from the chaff. This book provides guidelines for analyzing rapid-development information and finding the few grains of truth.

This book provides ready-made mental models that will allow you to assess what the silver-bullet vendors tell you and will also allow you to incorporate new ideas of your own. When someone comes into your office and says, "I just heard about a great new tool from the GigaCorp Silver Bullet Company that will cut our development time by 80 percent!" you will know how to react. It doesn't matter that I haven't said anything specifically about the GigaCorp Silver Bullet Company or their new tool. By the time you finish this book, you'll know what questions to ask, how seriously to take GigaCorp's claims, and how to incorporate their new tool into your development environment, if you decide to do that.

Unlike other books on rapid development, this book doesn't ask you to put all of your eggs into a single, one-size-fits-all basket. I recognize that different projects have different needs, and that one magic method is usually not enough to solve the schedule problems of even one project. I have tried to be skeptical without being cynical--to be critical of practices' effectiveness but to stop short of assuming that they don't work. I revisit those old, overhyped practices and salvage some that are still genuinely useful--even if they aren't as useful as they were originally promised to be.

Why is this book about rapid development so big?

Developers in the IS, shrink-wrap, military, and software-engineering fields have all discovered valuable rapid-development practices, but the people from these different fields rarely talk to each other. This book collects the most valuable practices from each field, bringing together rapid-development information from a wide variety of sources for the first time.

Does anyone who needs to know about rapid development really have time to read 650 pages about it? Possibly not, but a book half as long would have had to be oversimplified to the point of uselessness. To compensate, I've organized the book to be read quickly and selectively--you can read short snippets while you're traveling or waiting. Chapters 1 and 2 contain the material that you must read to understand how to develop products more quickly. After you read those chapters, you can skip ahead to whatever interests you most.

Why This Book Was Written

Clients' and managers' first response to the problem of slow development is usually to increase the amount of schedule pressure and overtime they heap on developers. Excessive schedule pressure occurs in about 75 percent of all large projects and in close to 100 percent of all very large projects (Jones 1994). Nearly 60 percent of developers report that the level of stress they feel is increasing (Glass 1994c). The average developer in the US works from 48 to 50 hours per week (Krantz 1995). Many work considerably more.

In this environment, it isn't surprising that general job satisfaction of software developers has dropped significantly in the last 15 years (Zawacki 1993), and at a time when the industry desperately needs to be recruiting additional programmers to ease the schedule pressure, developers are spreading the word to their younger sisters, brothers, and children that our field is no fun anymore.

Clearly our field can be fun. Many of us got into it originally because we couldn't believe that people would actually pay us to write software. But something not-so-funny happened on the way to the forum, and that something is intimately bound up with the topic of rapid development.

It's time to start shoring up the dike that separates software developers from the sea of scheduling madness. This book is my attempt to stick a finger into that dike, holding the madness at bay long enough to get the job started.

This material is Copyright © 1996 by Steven C. McConnell. All Rights Reserved.