Chapter 29. Selecting and Implementing Tools

Your team may need lots of tools for different purposes, all relating to quality. You need a good way to track bugs. You need practical and trustworthy source-code control. You may need a way to run executable tests through a user interface. We can't tell you exactly what path to follow; each situation is unique. Here are some guidelines that have helped us research and select tools.

It might seem obvious, but the first task in choosing a tool is to understand why you need the tool at all. What exactly does it need to do, and what features are critical? If you can't pinpoint these and just have a general requirement that the tool "take care of" a problem area, it's hard separate the wheat from the chaff when evaluating tools. Don't be seduced by bells and whistles that look cool in a demo but don't address what you really need.

Tools are useful, but they're only a start. Don't expect any tool to be a magic bean. A new and improved golf ball won't really make us hit drives like Tiger Woods. No matter how good your tools are, your team's success still comes down to you and your team members.

You need to know what kind of investment you can make in a tool: not just the purchase price but training costs, ramp-up time, time to implement and maintain the tool. If you're investing heavily in a tool, you may have to take the un-XP-like step of anticipating your future needs. If you're about to set off on a two-month car camping trip through the forty-eight states with your family of six, don't buy a two-seater sports car. The nature of XP projects usually dictates the use of low-cost, lightweight tools. However, every project is different, and you'll have to weigh the risk of not having the correct tool for the job against the cost of acquiring and using the tool.