Chapter 6. Core Issues in Rapid Development

Contents

6.1 Does One Size Fit All?

6.2 What Kind of Rapid Development Do You Need?

6.3 Odds of Completing on Time

6.4 Perception and Reality

6.5 Where the Time Goes

6.6 Development-Speed Trade-Offs

6.7 Typical Schedule-Improvement Pattern

6.8 Onward to Rapid Development

Related Topics

Rapid-development strategy: Chapter 2

ONCE YOU'VE LEARNED HOW TO AVOID the classic mistakes and mastered development fundamentals and risk management, you're ready to focus on schedule-oriented development practices. The first step in that direction is to understand several issues that lie at the heart of maximum development speed.

Does One Size Fit All?

You will use different practices to develop a heart-pacemaker control than you will to develop an inventory tracking system that tracks videotapes. If a software malfunction causes you to lose 1 video out of 1000, it might affect your profits by a fraction of a percent, but it doesn't really matter. But if a malfunction causes you to lose 1 pacemaker out of 1000, you've got real problems.

Different projects have different rapid-development needs, even when they all need to be developed "as fast as possible." Generally speaking, products that are widely distributed need to be developed more carefully than products that are narrowly distributed. Products whose reliability is important need to be developed more carefully than products whose reliability doesn't much matter. Figure 6-1 illustrates some of the variations in distribution and reliability.

Different kinds of software require different kinds of solutions. Practices that would be considered to be quick and dirty for an embedded heart-pacemaker control might be overly rigorous for an online cookbook.

Figure 6-1. Different kinds of software require different kinds of solutions. Practices that would be considered to be quick and dirty for an embedded heart-pacemaker control might be overly rigorous for an online cookbook.

The specific entries in the grid are intended to serve only as illustrations. You could argue about whether a video-display driver or a tax program needs to be more reliable or whether desktop-publishing software or spreadsheet programs are more widely distributed. The point is that both the extent of distribution and the required reliability vary greatly among different kinds of software. A software failure can cause a loss of time, work, money, or human life. Some schedule-oriented development practices that are perfectly acceptable when only time is at stake would be unconscionably reckless when human life is at stake.

CROSS-REFERENCE

For more on customizing software processes to the needs of specific projects, see Which Dimension Matters the Most?, Which Dimension Matters the Most?

On the other hand, practices that would be considered quick and dirty in a life-critical system might be overly rigorous for a custom business-software application. Rapid development of limited-distribution custom software could conceivably consist of what we think of as "workarounds" in more widely distributed software. Glue together some pieces that solve today's problem today, not tomorrow. Tomorrow might be too late—a late solution might be worthless.

As a result of this tremendous variation in development objectives, it's impossible to say, "Here's the rapid-development solution for you" without knowing your specific circumstances. The right solution for you depends on where you would place yourself on Figure 6-1's grid. Many products don't fit neatly into the grid's categories, and products vary in many ways other than degree of reliability and extent of distribution. That means that most people will need to customize a solution for their situation. As Figure 6-2 suggests, one size does not fit all.

One size does not fit all.

Figure 6-2. One size does not fit all.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.189.182.96