Rapid Development

Rapid Development

5.0 2
by Steve McConnell

View All Available Formats & Editions

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

…  See more details below


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.

Read More

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.

Product Details

Microsoft Press
Publication date:
Code Series
Edition description:
Sales rank:
Product dimensions:
7.30(w) x 8.90(h) x 1.60(d)

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...

Read More

Meet 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.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >

Rapid Development 5 out of 5 based on 0 ratings. 2 reviews.
Anonymous More than 1 year ago
Anonymous More than 1 year ago