The approach to rapid development that I lay out in this book is not the only approach that has ever been known to work. There is a different road that some projects have traveled successfully. That road is characterized by hiring the best possible people, asking for a total commitment to the project, granting them nearly total autonomy, motivating them to an extreme degree, and then seeing that they work 60, 80, or even 100 hours a week until either they or the project are finished. Rapid development with this commitment-based approach is achieved through grit, sweat, and determination.
CROSS-REFERENCE
For more on commitment-based approaches, see Commitment-Based Scheduling in Schedule Estimation and Chapter 34, Chapter 34.
This approach has produced notable successes, including Microsoft NT 3.0 and the Data General Eagle Computer, and it is unquestionably the most popular approach to rapid development in use today. For a start-up company with cash-flow concerns, it has the advantage of extracting two months' work from an employee for one month's pay. That can mean the difference between finishing a killer product in time to meet a marketing window that allows the company to make a fortune and running out of money before the team even finishes the product. By keeping team size small, it also reduces communications, coordination, and management overhead. If practiced with a keen awareness of the risks involved and with some restraint, the approach can be successful.
Unfortunately, this approach is hardly ever practiced that carefully. It usually devolves to a code-like-hell approach, which produces drawn-out projects that seem to last forever. The approach is a quick fix, and it shares many problems with other quick fixes. I criticize aspects of the approach throughout the book. Here's a summary.
The approach is hit-or-miss.Sometimes it works; sometimes it doesn't. The factors that make it work or not work are largely impossible to control. When you do manage to complete a project, sometimes you get the functionality you planned for; sometimes you're surprised. Sometimes you hit your quality targets; sometimes you don't. The approach makes specific product characteristics difficult to control.
It causes long-term motivation problems.On commitment-based projects, developers start out enthusiastically and put in ever-increasing overtime as they begin to fully realize what it will take to meet their commitments. Eventually, long hours aren't enough, and they fail to meet their schedule commitments. Their morale fades as, one by one, they are forced to admit defeat.
Once developers have put their hearts and souls into trying to meet their commitments and have failed, they become reluctant to make additional strong commitments. They start to resent the overtime. They make additional commitments with their mouths but not with their hearts, and the project loses any semblance of planning or control. It is not uncommon for a project that has reached this state to stay "three weeks from completion" for six months or more.
It's unrepeatable.Even if the code-like-hell approach succeeds once, it doesn't lay the groundwork for succeeding next time. Because it burns people out, it more likely lays the groundwork for future failures. A company cannot easily repair the human damage inflicted by such a project, and accounts of such projects invariably report that massive staff turnover accompanies them (see, for example, Kidder 1981, Carroll 1990, Zachary 1994).
It's hard on nonsoftware organizations. Because it's based on individual heroics rather than on coordination, cooperation, and planning, the code-like-hell approach provides little visibility or control to other stakeholders in the project. Even when you succeed in developing the software faster than average, you have no way of knowing how long the project will take. You don't know when you'll be done until you're actually done.
Some of the speed benefit arising from the commitment-based approach is neutralized because other groups that must coordinate with software developers—including testing, user documentation, and marketing—can't plan. In a code-like-hell project, frustration about the inability to get reliable schedule information from developers causes tempers to flare, and people within the development team are set against people outside the team. What's good for the software part of the project isn't necessarily good for the project overall.
It wastes human resources extravagantly. Developers who participate in this kind of project forego families, friends, hobbies, and even their own health to make a project successful. Severe personality conflicts are the rule rather than the exception. This level of sacrifice might be justifiable to win a war or put a man on the moon, but it isn't needed to develop business software. With few exceptions, the sacrifices aren't necessary: the same results can be achieved through careful, thoughtful, knowledgeable management and technical planning—with much less effort.
Table 2-2 summarizes some of the differences between the code-like-hell approach and the approach this book describes.
Table 2-2. Code-Like-Hell Approach Compared to This Book's Approach
Code-Like-Hell | This Book's Approach |
|---|---|
Source: Inspired by "Rewards of Taking the Path Less Traveled" (Davis 1994). | |
Proponents claim incredible, instant improvement in development time. | Proponents claim modest instant improvement followed by greater, long-term improvement. |
Requires little technical expertise beyond coding knowledge. | Requires significant technical expertise beyond coding knowledge. |
High risk: frequently fails even when done as effectively as possible. | Low risk: seldom fails when done effectively. |
Others will see you as "radical, dude." You'll look like you're giving your all. | Others will see you as conservative, boring, even old-fashioned. You won't look like you're working as hard. |
Wastes human resources extravagantly. | Uses human resources efficiently and humanely. |
Provides little progress visibility or control. You know you're done when you're done. | Permits tailoring the approach to provide as much visibility and control as you want. |
Approach is as old as software itself. | Key parts of the approach used successfully for 15 years or more. |
The approach this book describes achieves rapid development through careful planning, efficient use of available time, and the application of schedule-oriented development practices. Overtime is not uncommon with this kind of rapid development, but it does not begin to approach the mountain of overtime commonly found when the code-like-hell approach is used. Efficient development commonly produces a shorter-than-average schedule. When it fails, it fails because people lose their resolve to continue using it, not because the practice itself fails.
In short, the code-like-hell approach guarantees extraordinary sacrifice but not extraordinary results. If the goal is maximum development speed rather than maximum after-hours hustle, any betting person has to favor efficient development.
If you read between the lines in this book, you'll find all the information you need to conduct a code-like-hell project as successfully as possible. A person could certainly transform this book's Dr. Jekyll into code-like-hell's Mr. Hyde. But I personally have had more than my fill of that kind of development, and I'm not going to spell out how to do it!