Tools

Tools are perhaps the most interesting of the three keys to project success. Adopting tools requires a commitment of time to learn and use them. Sometimes we use tools ineffectively by trying to do too much, or not looking at whether the benefits outweigh the costs. Finally, there are times when we just use the wrong tool. There is an old saying that goes, "If you only have a hammer , everything looks like a nail." We have seen software projects work with only "hammers" and try to build skyscrapers. It just does not work.

We have just a few tool-oriented project guidelines. They are variations on a theme. The first one, Project Guideline 12, sets tools in context of the three keys to successful projects.

Project Guideline 12 Make sure tools are worth the effort

Ensure that your tools support the process and people on your project.

Tools are not an end in themselves . By definition, a tool is something that helps you do your job better. It is good to have a well-stocked tool set and be able to select the ones that will support your efforts. However, you need to make sure that you don't get too wrapped up in using tools for their own sake. We could restate Project Guideline 12 this way: Just because you have a tool doesn't mean you have to use it. This doesn't apply only to software tools and software projects. If you look around, you find that we are a society of gadget users. Look in your garage, attic, closets, and other hiding places and you'll find lots of gadgets that are not used, or were used for a while with poor results. Don't fall into this trap with the tool usage on your project.

The advice from Project Guideline 12 leads us to consider a corollary: Just because you are going to use a tool does not mean you have to use all of its features. We believe that there are few, if any, cases where all of the features of the tools we have are really necessary. Sometimes it takes much more effort to use the feature than to adopt another, simpler technique, or skip it all together.

Corollary 12.1 Use only the tool features you need

Use only the features of your tools that make you more efficient.

Our next project guideline (Project Guideline 13) relates tool usage to people (see Project Guideline 2, Provide a Learning Environment). Learning to use the tools properly is important, but is often ignored. We assume that the team members will learn how to use the available tools as they need them. This may be so, but they need to have instruction. The instruction can take many forms: classroom, mentor, books, or online training. Just don't neglect the real time spent in this effort and think it won't affect your project.

Project Guideline 13 Provide time to learn tool usage

Provide instruction on tool usage and schedule the learning time into your project.

The systems we attempt to build today are complex. We need tools that address the complexity and help us understand it. Few programmers today use just a text editor and a compiler. They use integrated development environments (IDEs) that help them construct the components for their application programs. Testers use tools that automate much of the repetitive work of testing, freeing up time to concentrate on developing effective tests.

Using tools effectively takes time. While most people can learn to use a tool with some degree of proficiency by themselves, it is almost always worth the cost to provide some help to them in their learning effort. We only need look around to see the difference in the productivity between power users of the tools and those who have only a basic knowledge.

Building Your Own Tools

When should you build your own tools? Should you build your own tools? Project Guideline 14 states our feelings on the subject.

Project Guideline 14 Build tools when necessary

Build your own tools when necessary, but make sure that the benefits outweigh the cost.

Every project needs to customize its process. Projects also have to customize the tools in their environment. In many cases, the tools available to you are excellent , general-purpose tools, but your team has special needs that the tools were not designed to address. If there is a good business case, try to extend existing tools, or build your own tools to do the job. Before you embark on a tool-building subproject , however, we suggest you consider the following:

• Do you really need the features that a special tool will deliver? Is the added functionality something that is nice to have or is it the case that you cannot successfully complete your project without the new features?

• Can you afford the cost of building your own tool and maintaining it? If you build a tool, you must maintain it, just as with any other software product. Project teams and organizations frequently fall into the trap of deciding to build a new tool without considering the full cost associated with it. As soon as you begin to use an internally developed tool, you establish a reliance on that tool. Any problems with the tool must be addressed, and you will probably find that you want to make extensions. Tool-smithing can become a full-time job for one or more team members. This may be all right, but you must be willing to accept the costs.

• Do you need to build a new tool or can you extend an existing one? Many software development tools are designed to be extended. The tool vendors provide an API and documentation for this purpose. This may be your best choice when you decide that you need new tool capabilities for your project.