FAQ 3.10 What is the right approach to processes and tools?

Select processes and tools based on business considerations rather than purely on technical grounds. Buy tools, don't build them. Customize existing processes; don't invent your own.

In general, the selections should be popular enough that they'll be around in five years, should be mature, should be consistent with the organization's skill levels, and should allow hiring new people who already have the necessary skills.

An important consideration is that the process should allow local variations. IBM's WSDDM is an example of this.

Technologists waste a lot of energy arguing the virtues and vices of the various design notations. As usual, business considerations should dominate technical considerations. UML is currently the most popular notation, and it is used in this book.

The emerging method of analysis and design from the "three amigos" (Booch, Jacobson, and Rumbaugh) associated with UML is pretty good and has been well received by the marketplace.

With respect to design tools, beware of "tool worship." Remember: tools don't produce designs; people produce designs. Tools capture the thoughts of the design team, but before the tool can add value, the design team first has to think some reasonably good thoughts. Some tools also generate skeleton code, but that's helpful only if the design is good. So tools are good, in that they capture and transmit ideas in a uniform manner, but underneath it all, design is much more human than mechanical.