Section 3.7. Choosing New Tools


3.7. Choosing New Tools

Whether you are choosing a tool for a new project or looking for a tool to replace one already in use, there are a number of helpful places to start.

First, other members of the project are likely to have suggestions for different tools. Send out a request for information, making sure it has an obvious deadline for replies. Specify what the tool must do and what you would merely like it to do. If there is a tool in current use, be very clear about what you believe the problems are with it. Be sure to ask people about whether they have actually used their recommended tool, not just evaluated it. Make sure you ask them whether they have administered the tool since using and administering tools can be very different experiences. (ClearCase is the classic example of this phenomenon.)

Other places to search for more information include:


Open Directory Project

The Open Directory Project (http://dmoz.org) claims that it's the largest human-edited directory of the Web. You won't find every tool in each category, but you'll probably find most of them.


Newsgroups

Don't use Google or some other search engine to search only web sites. Search the newsgroups as wellfor example, by using the Google Groups link. Company web sites' search forms may also turn up information that is not available from other search engines.


Discussion web sites

Slashdot (http://slashdot.org) and other opinionated forums are sure to reflect a diversity of thoughts about the tools. Some of these opinions may be based on experience, but many are surely not. Caveat lector, or "let the reader beware."

A number of web sites, magazines, books, and other resources for choosing tools are listed in Appendix B.

3.7.1. Steps When Changing Tools

When you have decided that a tool must be changed and you have some ideas about what to replace it with, there are a number of steps to follow:

  1. It is helpful to start with a clear and broadly agreed-on understanding of what the tool must do and not do, and what features would be useful but are not essential. These requirements will probably change as you investigate the available options, but they're a good place from which to start.

  2. Create a document that summarizes the different choices and their perceived advantages and disadvantages, or rate them in a number of different areas. Make sure you know which requirements are mandatory and which are merely desirable. Propose some tentative schedules for how the tool could be introduced.

  3. Evaluate the two or three leading choices, ideally by installing them locally on a development machine and using them with your own data or files. Record all the key information about installing, configuring, and using a new tool while you are doing it and it is fresh in your mind. Other ways of evaluating an open source tool are reading the source code and looking at the number of bugs, the number of messages on mailing lists, the amount of recent SCM activity, and the download statistics, if available.

  4. Talk with senior developers on your project about their impressions of each tool. Ask the tool's vendor or project administrators for names of people who already use the tool that you can talk to. Add all these comments to the document, but keep them separate from each other, since they come from different perspectives.

  5. Discuss the document with the senior members of the group and come to a decision. It helps if you can make a business case for the cost of each tool and the expected return on investment. Add people's names and a date, and save this document for revisiting in the future when people ask why a particular tool was chosen.

  6. Document how you expect the new tool to be used and send this out to the whole project. Offer to describe it in person if your numbers and locations permit.

  7. If at all possible, bring up the new tool in parallel with an existing tool and migrate people to the new tool gradually. If a switchover date is necessary, publicize it well in advance and make sure that extra support is available for the tool when it goes live.

  8. Archive and move the old tool aside so that it isn't used by mistake or ingrained habit. It may still occasionally need to be used in the futureit may still be required for generating patches for older releases. If the tool is installed on peoples' individual machines, send detailed instructions about how to migrate safely from the old tool to the new one.

  9. Update the documents about the development environment, especially the documents for new developers.

Some tools will need to have their data exported and then imported into the new tool. Bug tracking systems are one example of this; SCM tools are another. While you are migrating this data, it's worthwhile to consider how you will export the data from the new tool into yet another tool a few years from now. This is one area where file formats that are openly available and well documented will make your life much easier.

Finally, no matter how easy the transition to the new tool is, expect some level of complaintit's the cosmic background radiation of software projects.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net