The design-to-tools lifecycle model is a radical approach that historically has been used only within exceptionally time-sensitive environments. As tools have become more flexible and powerful—complete applications frameworks, visual programming environments, full-featured database programming environments—the number of projects that can consider using design-to-tools has increased.

The idea behind the design-to-tools model is that you put a capability into your product only if it's directly supported by existing software tools. If it isn't supported, you leave it out. By "tools," I mean code and class libraries, code generators, rapid-development languages, and other software tools that dramatically reduce implementation time.

As Figure 7-12 suggests, the result of using this model is inevitably that you won't be able to implement all the functionality you ideally would like to include. But if you choose your tools carefully, you can implement most of the functionality you would like. When time is a constraint, you might actually be able to implement more total functionality than you would have been able to implement with another approach—but it will be the functionality that the tools make easiest to implement, not the functionality you ideally would like.

Figure 7-12. Design-to-tools product concept. Design-to-tools can provide exceptional development speed, but it typically provides less control over your product's functionality than other lifecycle models would provide.

This model can be combined with the other flexible lifecycle models. You might conduct an initial spiral to identify the capabilities of existing software tools, to identify core requirements, and to determine if the design-to-tools approach is workable. You can use a design-to-tools approach to implement a throwaway prototype, prototyping only the capabilities that can be implemented easily with tools. Then implement the real software using one of the other lifecycle models. You can also combine this model with staged delivery, evolutionary delivery, and design-to-schedule.

The design-to-tools model has a few main disadvantages. You lose a lot of control over your product. You might not be able to implement all the features that you want, and you might not be able to implement other features exactly the way you want. You become more dependent on commercial software producers—on both their product strategies and their financial stabilities. If you're writing small, mostly disposable programs, that might not be much of a problem; but if you're writing programs that you intend to support for a few years, each vendor whose products you use potentially becomes a weak link in the product chain.