The road mapped out in this book is clearly the road less traveled in today's industry. Switching to the road less traveled might seem risky. But the road more traveled is the road that is currently resulting in massive cost and schedule overruns; low quality; canceled projects; high turnover; friction between managers, developers, and customers; and all the rest of the problems we're trying to get rid of.
If you work in a typical organization and follow the practices in this book, you'll be able to cut your development time significantly, perhaps by as much as half, and boost your productivity significantly, too. You'll be able to do that without harming quality, cost, performance, or maintainability. But the improvement won't come instantly, you won't attain it from any single new tool or method, and you won't attain it merely by taking the shrink-wrap off the box. It will take time and effort.
I wish I had a simple solution to the development-speed problem. I also wish I had five million dollars. But simple solutions tend to work only for simple problems, and software development isn't a simple problem. Rapid development of software is even less simple.
For every complex problem, there is an answer that is short, simple, and wrong. | ||
| --H. L. Mencken | ||
As Figure 1-1 suggests, the set of all available software practices is huge. Within that set, the subset of effective practices is also quite large. You use only a small sub-subset of those practices on any particular project. At an executive-overview level, success at rapid development consists of two elements:
Choosing effective practices rather than ineffective practices
Choosing practices that are oriented specifically toward achieving your schedule objectives
Figure 1-1. Set of all software-development practices. Development speed depends on the choice of development practices. How rapidly you develop any particular program depends on the extent to which you choose effective practices and on the extent to which you choose schedule-oriented practices.
You might think this is obvious, but, as Chapter 3 explains, organizations routinely choose ineffective practices. They choose practices that are proven failures or that fail more often than they succeed. When they need maximum scheduling certainty, they choose high-risk practices that reduce the chance of meeting their schedule goals. When they need to reduce costs, they choose speed-oriented practices that drive costs up. The first step toward improving development speed for those organizations is to admit that they're choosing ineffective practices and then to begin choosing effective ones.
All of the effective schedule-oriented practices are lumped into one category in Figure 1-1, but, as Figure 1-2 suggests, you actually have a choice among three kinds of schedule-oriented practices:
Practices that improve development speed, allowing you to deliver software faster
Practices that reduce schedule risk, allowing you to avoid huge schedule overruns
Practices that make progress visible, allowing you to dispel the appearance of slow development
Figure 1-2. Schedule-oriented practices come in three kinds: practices that enable you to develop faster, reduce schedule risk, and make your progress visible.
The specific kinds of schedule-oriented practices you choose will be determined by your specific concerns about development speed. If you think you genuinely need to develop faster, you should focus on speed-oriented practices. If you think that your development speed is OK and that your customer's perception of your development speed is the problem, you should focus on visibility-oriented practices.
When you put effective schedule-oriented practices together with a plan for using them, you'll find that the whole package provides for dramatic, real improvements in development speed. That's better than using a Magic-Beans™ software cure-all that doesn't really work. Of course, choosing effective practices and avoiding ineffective practices is easier said than done, and that's what the rest of the book is about.