My thinking often returns to tools. Whether philosophically or practically, the idea of the tool fascinates me. I first became aware of the question of tools through the writings of philosophers like Plato, Aristotle, Heidegger, and Gadamer--tools, devices, equipment, the in-order-to, the ready-to-hand, the hammer vs. the hammering-hand. One of the difficulties of tools is that they rarely reveal themselves, unless they are broken. We don't think about the hammer when it is hammer, and we are hammering; we might notice it if we hit our thumb or bruise the wood. Thinking about tools requires one to put them down long enough for them to become visible as objects separate from the intention of their users.
Most writers, when they speak of tools, think in terms of the physical world. I come from a long line of farmers and tinkerers for whom tools in the workshop, barn, or basement were a critical component of one's existence. My father has an amazing array of tools, many of which I have no idea how to use. And yet I too have an enormous collection of tools. The tools I use most often are made of software, and it is toward these tools that I now want to turn.
I had an interesting conversation with Christian Legnitto a few weeks ago on the subject of tools in software (one, two, three, four, five also, Twitter, why is it so hard to link to this?). That conversation foregrounded tools once again, and at Johnathan's request, I'm going to try and say something about the place and purpose of tools in software projects.
The first thing to notice about tools in software, what I'll call tools() in order to differentiate them from what we normally mean when we say tools, is that they don't exist in a form separate from the thing on which they operate. Any trip into my father's basement or garage instantly reveals the presence of certain objects. These tools have a physicality beyond their intentionality and purpose. The process of the hammering-hand and the physicality of the hammer hanging on the wall are distinct.
On the other hand, when one examines a tool(), it becomes clear that there is only process. A tool() is a repeatable process run at speed and scale. A tool() is what I used to do manually but have now automated. One of the main goals of a tool() in a software project is to provide the means for an again. The tool() isn't something I pickup or use so much as something I've done, and am intending to do again.
What do tools() do? They compile source code; blur images; download files; version data; sort data; search files; visualize information. In every case a tool() does something that we could do by hand, but without speed or scale. A tool() reduces time and space, and makes human an inhuman task.
We see some of this in the tool as well. We call the man who can run 42 Km (26 miles, for my American readers) a hero, while the man who bikes the same distance (or drives it in his convertible) is enjoying an afternoon outside. In both cases our manual energy is required. However in the latter case, the bicycle is more efficient at converting it into distance.
I used the word "hero" above, and was intentional about doing so. In software projects the main goal of tools() is to convert heroic acts into everyday tasks. Tools(), and those who create them, seek to remove the heroic from the creation of software. Like all good mythologies, tales of software heroes abound. We can all name heroes we know, or heroes we collectively know, who have done the impossible with code and computers.
These stories feel good, and connect us to a tradition of storytelling. They also hide the reality of software projects. I've worked on many software projects, and come to understand that software is never built with heroics--not good software, not large software, and certainly not shipping software. The mythology of software is that "Mark" built this. The reality is that a large team did.
Those who haven't worked on a team before may not have encountered tools() in the way I'm describing. The team requires tools() in order to depend on what would otherwise require heroes. While central to the mythology of the battlefield, the hero is anathema to shipping software, and especially software the needs to ship again.
Considering, as I've said, that tools() demythologize, that a tool() is a process for removing heroics from software projects, and that tools() are processes meant to shrink size and collapse time, we have to invest in their creation. Successful software projects are full of tools(), from build systems to test harnesses, profilers to continuous integration systems, linters to compilers. All of them seek to reduce the need for heroics, to make mundane the exceptional.
To get tools(), one needs to always look within a team for the places where heroics are still required. The processes that can't be easily replicated, the knowledge that only a few people have, the process that takes hours or days to complete--these need to get transferred into tools(). We have to invest in this activity, make it part of our culture, resist the hagiography of technical giants and prefer the process-turned-tool that allows for easy repeatability by anyone on the team.
Tools(), like tools, suffer from invisibility when they work. It is the nature of a good tool that it shouldn't reveal itself while in use. As our tools() become better and more sophisticated, we can lose our connection with them, especially their genesis. If we can't see our tools() anymore, we also lose sight of their history, the way it used to be, the heroics that were once involved in running 42 Km vs. the bicycle ride (or car trip!) we now enjoy. The risk is always complacency, the forgetting of the pain and dysfunction that predated the tool()'s existence.
If we don't make an effort to quantify and present a tool() to our team, if we don't bear the memory of what came before the tool(), we devalue the culture that brings about tools() in the first place. When we can say that this tool() is saving us X hours, Y gigabytes, or Z steps, we help elevate history over mythology. It's important to celebrate the hero by converting his or her act into a tool() that renders it obsolete.
Tools() need to be valued by the culture of a project. There needs to be discussion of their worth, and reflection on what they replace. We need to make time for their creation and maintenance. We need to continually ask ourselves why we are relying on heroics and heroes. A tool() should replace a hero, allow Sisyphus to cease pushing the stone to the top of the hill.