Section 12.1. The Role of the Toolsmith

12.1. The Role of the Toolsmith

In traditional factories (that is, factories that produce things you can actually pick up and drop on your toes), there is often a tools department. This department is responsible for producing and maintaining the tools used by the other workers. The members of the tools department are called toolsmiths. Much of this book has been about choosing and using different tools to provide a satisfying software development environment. The people who do this are acting as toolsmiths for their software projects. However, in many projects the position of a toolsmith is not properly filled, and each worker just uses whatever tools are familiar and comfortable. Interestingly, this is the same situation that small-scale craftsmen were in before the Industrial Revolution.

The Apprentice

A traditional introduction of an apprentice to the toolsmiths in a factory:

Senior worker to Apprentice: Go down to Tools and tell 'em you need a long weight.

(Later on . . . )

Apprentice to Toolsmith: I need a long weight!

Toolsmith: Fair enough, you just wait right there and I'll be with you in a while.

And indeed the apprentice had a long wait ahead of him.

(More of these "sleeveless errands" can be found at http://www.museumofhoaxes.com/af_1700s.html.)

Some smarter companies and projects do have people who are specifically designated toolsmiths for the software. These organizations believe that, just as a product works better when it has been designed (rather than being allowed to just grow irregularly over time), a well-thought-out environment produces better products than does an environment that is a haphazard collection of whatever tools seemed useful at some point. For instance, this book was produced with the assistance of the Production Tools group at O'Reilly, which supports the production editors who shepherd a book from the author's source files to the printed copy and online version.

I'm not aware of any hard financial or organizational results to justify employing a toolsmith for your project, but the idea of a tools department seems to have generally done good things for the Industrial Revolution, so I recommend it.

So, what is the role of a toolsmith? Each of the chapters in this book describes a part of what a toolsmith can be expected to be involved in. To recap, these areas are: SCM, builds, testing, tracking bugs, documentation, release, and maintenance. Any and all of these areas are good places for toolsmiths to contribute to a project. In the wide-ranging paper "The Computer Scientist as Toolsmith II" (http://www.cs.unc.edu/~brooks/Toolsmith-CACM.pdf), Fred Brooks (author of The Mythical Man-Month) wrote:

If the computer scientist is a toolsmith, and if our delight is to fashion power tools and amplifiers for minds, we must partner with those who will use our tools, those whose intelligences we hope to amplify.

A good question is "What does a toolsmith usually not do?" The toolsmith should not try to be an architect or designer for the project. The toolsmith should also not be a long-term developer for the project. The thought behind both of these opinions is that anything long-term that distracts the toolsmith from the development environment means that the environment stops being maintained, and then the rest of the group will suffer as a consequence. However, as discussed below, a few weeks spent developing, testing, and documenting by a toolsmith can produce a crystal-clear understanding of the real problems faced by those groups.

Since a toolsmith is a service provider, some customer-service types of activities are often helpful:

• Gather feedback from the group regularly. What are the top three irritations? What solutions can they suggest? If they aren't too vague, you can file bugs on these problems and update the bugs as changes are made.

• Don't let fires burn out of control. As soon as there are whispers of discontent about some aspect of the environment, create a document about how it's supposed to be used, print copies of the document to give out to project members, and offer to give a short talk about it. If there really is a problem, then create a bug about it and refer people to the bug to add comments. If possible, schedule a time when the problem can be fixed.

• Providing regular updates about the status of the environment (what's working, what's broken, and when will it be fixed) to the group and to management will also help manage their perceptions of the environment's status.

• Keep a clear trail of decisions and feedback from all parties. Sign all your email cryptographically, print out key documents, and store them securely off site. Keep records not just of license files, but also who was responsible for choosing each tool.

Another valuable form of feedback for the toolsmith is to have to use the environment he has created, also known as "eating your own dog food." Though I don't recommend this as a long-term practice (since it distracts from the maintenance of the environment), this is a good idea in the short term. For instance, try entering six bugs in one sessionwhich is the slowest part of the whole process? Debug a problem in a file that is used by large numbers of other files and see how slow the rebuilds really are. Try to fix a broken unit test and then rerun the test suite by hand. I guarantee that the results of these activities will bring a clearer understanding of a group's complaints to any working toolsmith.

A toolsmith should also try to avoid making off-the-cuff policy decisions about subjects such as who has access to different parts of the source code, when SCM branches are created, or whether a particular bug really is a critical show-stopper. The toolsmith provides mechanisms to support policies and may well make strong recommendations about how to use the tools, but policy decisions really ought to come from the project leaders and managers.

A good toolsmith also has to be nonpartisan about tools that she does not control. The classic example here is the choice of file editors for Unix: Emacs or vi. Both editors are in common use, and the arguments about which is better, and better for what, have raged for decades now. A toolsmith cannot dismiss one editor or the other, no matter her personal preferences (even mine are considered secret). However, it is fair for a toolsmith to restrict official support to a limited number of tools, in order to be able to provide adequate time for each one.

12.1.1. How to Choose a Toolsmith

While there is rarely a clear career path for software toolsmiths (most of us seem to be developers who have come to specialize in tools), here are some ideas for what to look for on a résumé or to ask for in a job description for a toolsmith:

• Experience with at least two different SCM tools, two different build tools, and two different bug tracking systems.

• Both administrative and user experience with tools. There is a world of difference between using a tool and administering the same tool for a large group of people.

• Demonstrated ability to identify the causes of problems in a development environment in a systematic way.

• Ability to summarize problems in an environment, to propose and evaluate solutions for the problems, and then to implement the solutions in a reasonable amount of time.

• For each of the projects he has been involved with, can he identify the most significant mistakes that he personally made? If he says there were no mistakes, either hire him immediately or treat the rest of his comments as highly suspect!

• What books, magazines, newsgroups, mailing lists, web sites, or weblogs that discuss tools and development environments does she read on a regular basis? Appendix B contains suggestions about some appropriate ones you should expect to hear.

It's interesting to note that while many of these abilities are very similar to those required for developers writing code, it is not essential (though it is definitely helpful) for a toolsmith to be able to write source code. In a few projects, the managers are the toolsmiths for the project.