Rapid Development

by Steve McConnell

Overview

Corporate and commercial software-development teams all want solutions for one important problem—how to get their high-pressure development schedules under control. In RAPID DEVELOPMENT, author Steve McConnell addresses that concern head-on with overall strategies, specific best practices, and valuable tips that help shrink and control development schedules and keep projects moving. Inside, you’ll find:

• A rapid-development strategy that can be applied to any project and the best practices to make that strategy work
• Candid discussions of great and not-so-great rapid-development practices—estimation, prototyping, forced overtime, motivation, teamwork, rapid-development languages, risk management, and many others
• A list of classic mistakes to avoid for rapid-development projects, including creeping requirements, shortchanged quality, and silver-bullet syndrome
• Case studies that vividly illustrate what can go wrong, what can go right, and how to tell which direction your project is going
• RAPID DEVELOPMENT is the real-world guide to more efficient applications development.

Product Details

ISBN-13:	9780735646360
Publisher:	Pearson Education
Publication date:	07/02/1996
Series:	Developer Best Practices
Sold by:	Barnes & Noble
Format:	eBook
Pages:	672
File size:	7 MB

About the Author

Steve McConnell is recognized as one of the premier authors and voices in the development community. He is Chief Software Engineer of Construx Software and was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of Software Development magazine's Productivity Award. He is the author of several books, including Code Complete and Rapid Development, both honored with Software Development magazine's Jolt Award.

Read an Excerpt

From Chapter 9: Beating Schedule Pressure

Focus on Interests, Not Positions

Suppose you're selling your car in order to buy a new boat, and you figured that you need to get $5000 for your car in order to buy the one you want. A prospective buyer approaches you and offers $4500. You say, "There's no way I can part with this car for less than $5000." The buyer says, "$4500 is my final offer."

When you negotiate in this way, you focus on positions rather than interests. Positions are bargaining statements that are so narrow that in order for one person to win, the other person has to lose.

Now suppose that the car buyer says, "I really can't go over $4500, but I happen to know that you're in the market for a new boat, and I happen to be the regional distributor for a big boat company. I can get the boat you want for $1000 less than you can get it from any dealer. Now what do you think about my offer?" Well, now the offer sounds pretty good because it will leave you with $500 more than you would have gotten if the buyer had just agreed to your price.

Underlying interests are broader than bargaining positions, and focusing on them opens up a world of negotiating possibilities. Your boss might start out by saying, "I need a Giga-Blat 4.0 in 6 months," and you might know immediately that you can't deliver it in less then 9 months. Your boss's interest might be keeping a promise made to the sales organization, and your interest might be working less then 60 hours a week for the next 6 months. Between the two of you, you might be able to create a product that would satisfy the sales organization and would be deliverable within 6months. If you focus on interests, you're more likely to find a win-win solution than if you dig into bargaining positions.

One of the major problems with schedule negotiations is that they tend to become one-dimensional, focusing only on the schedule. Don't get dug into a position. Make it clear that you're willing to consider a full-range of alternatives--just not pie-in-the-sky options. If other people have dug themselves into demanding a specific schedule, here are some points you can use to dislodge them:

Appeal to true development speed. Point out that the worst fault of overly optimistic schedules is that they undermine actual development speed. Explain the negative effects of overly optimistic scheduling that were described in Section 9.1. True rapid development requires that you be firmly connected to reality, including to a realistic schedule.

Appeal to increasing the chance of success. Point out that you have estimated the most likely completion date and that you already have only a 50/50 chance of meeting that. Shortening the schedule will further reduce your chances of completing on time.

Invoke your organization's track record. Point to your organization's history of underestimating projects, coming in late, and all the problems that lateness has caused. Appeal to the other person's good sense not to do the same thing again.

Invent Options for Mutual Gain

Rather than thinking of negotiating as a zero-sum game in which one person wins at the other's expense, think of it as an exercise in creative problem-solving; the truly clever negotiator will find a way for both parties to win.

Your most powerful negotiating ally in schedule negotiations is your ability to generate options that the other person has no way of knowing about. You hold the key to a vault of technical knowledge, and that puts the responsibility for generating creative solutions more on your shoulders than on the nontechnical person you're negotiating with, It's your role to explain the full range of possibilities and trade-offs.

I find it useful to think about how many degrees of freedom there are in planning a software project. The basic degrees of freedom are defined by the schedule, cost, and product triangle. You have to keep the three corners in balance for the project to succeed. But there are infinite variations on that triangle, and the person you're negotiating with might find some of those variations to be a lot more appealing than others. Here are some of the degrees of freedom you might suggest related to the product itself:

• Move some of the desired functionality into version 2. Few people need all of what they asked for exactly when they asked for it.
  

• Deliver he product in stages--for example, versions 0.7, 0.8, 0.9, and 1.0--with the most important functionality coming first.
  

• Cut features altogether. Features that are time-consuming to implement and often negotiable include the level of integration with other systems, level of compatibility with previous systems, and performance.
  

• Polish some features less-implement them to some degree, but make them less fancy.
  

• Relax the detailed requirements for each feature. Define your mission as getting as close as possible to the requirements through the use of prebuilt commercial components.
  

Here are some degrees of freedom related to project resources:

• Add more developers, if it's early in the schedule.
  

• Add higher-output developers (for example, subject-area experts).
  

• Add more testers.
  

• Add more administrative support...

Table of Contents

• Part I: EFFICIENT DEVELOPMENT
  • Chapter 1: Welcome to Rapid Development
  • Chapter 2: Rapid-Development Strategy
  • Chapter 3: Classic Mistakes
  • Chapter 4: Software-Development Fundamentals
  • Chapter 5: Risk Management
• Part II: RAPID DEVELOPMENT
  • Chapter 6: Core Issues in Rapid Development
  • Chapter 7: Lifecycle Planning
  • Chapter 8: Estimation
  • Chapter 9: Scheduling
  • Chapter 10: Customer-Oriented Development
  • Chapter 11: Motivation
  • Chapter 12: Teamwork
  • Chapter 13: Team Structure
  • Chapter 14: Feature-Set Control
  • Chapter 15: Productivity Tools
  • Chapter 16: Project Recovery
• Part III: BEST PRACTICES
  • Introduction to Best Practices
  • Chapter 17: Change Board
  • Chapter 18: Daily Build and Smoke Test
  • Chapter 19: Designing for Change
  • Chapter 20: Evolutionary Delivery
  • Chapter 21: Evolutionary Prototyping
  • Chapter 22: Goal Setting
  • Chapter 23: Inspections
  • Chapter 24: Joint Application Development (JAD)
  • Chapter 25: Lifecycle Model Selection
  • Chapter 26: Measurement
  • Chapter 27: Miniature Milestones
  • Chapter 28: Outsourcing
  • Chapter 29: Principled Negotiation
  • Chapter 30: Productivity Environments
  • Chapter 31: Rapid-Development Languages (RDLs)
  • Chapter 32: Requirements Scrubbing
  • Chapter 33: Reuse
  • Chapter 34: Signing Up
  • Chapter 35: Spiral Lifecycle Model
  • Chapter 36: Staged Delivery
  • Chapter 37: Theory-W Management
  • Chapter 38: Throwaway Prototyping
  • Chapter 39: Timebox Development
  • Chapter 40: Tools Group
  • Chapter 41: Top-10 Risks List
  • Chapter 42: User-Interface Prototyping
  • Chapter 43: Voluntary Overtime
• Bibliography

Introduction

Corporate and commercial software development teams all want solutions for one important problem--how to get their high-pressure development schedules under control. In Rapid Development, author Steve McConnell addresses that concern head-on with overall strategies, specific best practices, and valuable tips that help shrink and control development schedules and keep projects moving.
Inside, you'll find:

• The best rapid-development strategies that can be applied to any project
• Candid discussions of great and not-so-great rapid-development practices--estimation, prototyping, forced overtime, motivation, teamwork, rapid-development languages, risk management, and many others
• A list of classic mistakes to avoid for rapid-development projects, including creeping requirements, shortchanged quality, and silver-bullet syndrome
• Case studies that vividly illustrate what can go wrong, what can go right, and how to tell in which direction your project is headed

Rapid Developement is the real-world guide to more efficient applications development

Editorial Reviews

Fatbrain Review

A fundamental software engineering project management guide based on the practical requirements of "Taming Wild Software Schedules." Emphasizes possible, realistic and "best practice" approaches for managers, technical leads and self-managed teams. The author emphasizes efficient development concepts with an examination of rapid development strategies and a study of classic mistakes, within the context of software-development fundamentals and risk management. Dissects the core issues of rapid development, lifecycle planning, estimation and scheduling. Contains very good and practical discussions of customer-oriented development, motivation and teamwork. Explains such fundamental requirements as team structure, feature-set control (the dreaded feature creep in every project), availability and use of productivity tools and project recovery options. Relevant case studies are analyzed and discussed within the context of specific software development problems. Over 200 pages in this publication are devoted to a summary of best practices, everything from the daily build and smoke test, through prototyping, model selection, measurement, reuse, and the top-10 risks list.

This publication is definitely recommended and will become a classic in the field, just as the author's prior publication, Code Completealready is.

Biting the Silver Bullet

Pop Quiz: What do Charles Petzold's Programming Windows and Andrew Schulman's Undocumented DOS have in common? Your knee-jerk reaction would probably be, "Not very much!" Philosophically, the two books lie at extreme opposite ends of the programming spectrum. Yet, on a more abstract level, the books are members of the same exclusive club: they established a new genre or ecological niche in computer trade book publishing, and then -- by virtue of their authority, comprehensiveness, and readability -- went on to dominate that niche for many years.

Steve McConnell's Rapid Development is instantly recognizable as another member of that rare breed of highly original and definitive books. It addresses a dire need in mainstream commercial or "shrinkwrap" software development that was previously unmet and only dimly perceived. It integrates a vast amount of practical information within a logical, easily grasped structure. It is soundly grounded in the author's mastery of his subject and common sense, and it is backed up by hundreds of references. And, last but hardly least, it is beautifully written in an economical, direct style that makes every page count.

For those of you who are (justifiably) skeptical about the extravagant claims made for "Rapid Application Development" (RAD) products, fear not --this book is not about CASE or Visual Basic. RAD development tools are certainly described in the book, but only as one arrow in a quiver of many. Rather, Rapid Development is a wide-ranging book on the professional and fact-based management of software development projects, with "rapid(er) development" as the hook.

The chapters of Rapid Development are organized under the umbrella of three main themes. The first section is principally concerned with "efficient development" rather than "rapid development" -- focusing in on fundamental technical and management principles, assessment and management of risk, and avoidance of classic mistakes. Proper attention to these areas makes schedules and costs at least predictable. Most of the topics are illustrated with entertaining (and sometimes painfully familiar) case histories.

The second section is a detailed exploration of a diverse strategies, techniques, and tools for speeding up the development process. Each topic, ranging from lifecycle planning to improving the motivation of developers, gets the careful, thoughtful treatment that is McConnell's hallmark. The chapters on estimation, scheduling, and feature-set control are especially valuable. I've read about code size estimation and software project scheduling many times elsewhere, but only after reading Rapid Development did I truly believe.

The last section of the book is a collection of mini-essays on 27 "best practices"in a common format. Each begins with a table that summarizes the technique's efficacy in various domains, major risks, interactions, and tradeoffs. The table is followed by a (sometimes extensive) discussion of usage, risk management, side effects, and "keys to success" for the practice at hand. Citations for further reading on each "best practice" are often provided as well.

In Rapid Development, we are privileged to see a virtuoso author/programmer and a superb editing and publishing team working together at the top of their form. Very few books I have encountered in the last few years have given me as much pleasure to read as this one. The only teensy quibble I have with the book is a design issue -- elimination of the excessive white space and the slightly patronizing "hard facts," "classic mistake," and "cross-reference" icons and tags in the left margins would have shortened the book by a hundred pages or more and saved quite a few trees.--Dr. Dobb's Electronic Review of Computer Books

Ray Duncan