Although there is much science in creating programs, programming itself still remains a creative process. Many programmers are craftsmen, putting a piece of themselves into their work. The best programmers, like the best craftsmen, learn their tools. They develop a deep understanding of each tool’s strengths and weaknesses, and they develop a certain level of comfort in using the tool. Because of this personal comfort level, some programmers tend to feel that their selected tool is the best, and for them, that may be true. People are often more productive when they are using tools with which they are most familiar and comfortable. The point of all of this is that the tools we use every day are often a matter of personal choice and preference. There is another point of view. Many organizations see the advantage in having a standardized set of development tools. The advantages of this include: a shared common team experience, group learning, and mentoring. This can be especially important to large project teams where tool differences can pose barriers to sharing code and shifting responsibilities.
In these cases, it is often acceptable to sacrifice certain amounts of short-term individual productivity to improve the overall productivity of the team. So which point of view is better? The answer is: it depends. Just like any other decision in the software development process this one depends on the people involved. In many cases, developers are more productive when using the tools with which they are most familiar. New tools can be added to the mix, and as developers decide that new tools are better than the old ones, they will usually switch. New tools can change the way we work. For example, for years when John wrote programs, he kept language and library references right next to him. When he could not remember the syntax for a rarely used statement, or the parameters for a particular function call, he would look them up in the book. Now, if John is using an Integrated Development Environment (IDE), all he has to do is start typing the command and hit a single key to instantly see the reference or have the editor complete the statement for him. This is an important timesaver: He no longer has to remember the syntax for the language he’s programming in because the tool will remember it for him. For complex Web applications, you may have to program in several languages at the same time, including HTML, XML, Java, Javascript, Perl, PHP C++, and Visual Basic for Applications. New tools can also add new capabilities. For example, many seasoned
developers have learned the importance of testing their own code. When you develop new classes, you may regularly create main methods just to exercise the class and make sure that it works as expected. (Frankly, this was easier in C and C++, where you could use a compiler switch to determine if the main function would be compiled into the module). There are now tools, such as jUnit, which allow you to create a suite of tests. You can write individual tests for each class and method and then exercise all of your classes at once. In light of this, it makes sense to allow developers to use the tools that they are most comfortable with, and also to encourage experimentation with new tools. However, for teams, certain tools need to be standardized. The tools that need to be standardized are the ones that will be shared across the team. Source code repositories are an example. The entire team must be able to retrieve code from the repository and update code within the repository. However,there is little need to standardize the client used as long as the team can
share the same repository. In summary, tools that are team oriented need to be selected for the team and should be common to all members. Developers should be able to select the tools that are individually focused.
