Mistaking the tool for the practice

As a developer I’m always on the lookout for the best applications, the fastest machines and the latest, most colourful updates to a product line. But sometimes I find that this can be unhealthy, addictive behaviour and so slowly, over the years, I’ve tried to become more critical of the tools around me. There are two questions that I try to ask as often as possible.

  1. How does this [app/feature/machine/code editor etc.] influence my design and development process?
  2. What can I learn from this tool beyond the immediate and fleeting short-term gains?

It’s strange to think in this way though. Why should a tool do anything more than what it was designed to? Well, I think these sorts of questions give us ample opportunities to learn more about why we work in the ways that we do. Why these apps or services? What is it about their functions and style that is of interest in this field? What does this combination of techniques say about the rest of the industry collectively?

What tends to bother me is when others fetishise the instruments that they use, for example in an interview when a designer or developer is asked to list their favourite applications. These might be useful in the short term but so little is revealed about their work. It’s here that we let our short term needs for the tool get in the way of the long term benefits of the working process.

There’s a great interview with Jack Cheng, the writer and designer of These Days, in which he’s asked a similar sort of question. His response reminded me of this conflict between applications and methods when he replies:

True fulfilment and productivity come from applying your tools with intent. The tools can be lo-fi or hi-fi, analog or digital, but the intent stems first and foremost from a mastery over self. Your tools will not save you.

There’s an even bigger risk though; when someone can’t tell the difference between the tool and the overarching practice. This can cause all sorts of problems, but perhaps the most infamous example of this is with the introduction of the horseless carriage in the late 19th century. Before the motorcycle and the automobile were given their respective names, the horseless carriage was used to describe every sort of vehicle available. It described everything from the small to the very large, from the heavy to the very light.


Hundreds of years with the horse as the primary mode of transportation had confused people, and rightly so. Over time the meaning of the word ‘horse’ had become synonymous with the word ‘transport’ to such an extent that anything that hauled people about without a horse was, as ridiculous as it might sound, still horse-like. This term manages to capture how much people had mistaken the tool for the process.

However, sometimes those items that we use everyday can be designed to teach us more about their inner workings and why they perform a certain function in a particular way. Last month I was obsessed with Inuit.css, an object oriented CSS framework that sets out to give front-end developers a set of rules which they can then use to scale a design system across a large web project. Essentially it’s a Lego like, ready-made sandbox for teams to work as efficiently as possible. Within this system they’re forced to break down every layout component into a series of objects. As a developer that constantly gets dazzled with large Sass files and partials hidden all over the place, it was a breath of fresh air to see this sort of stylesheet control panel, dotted with neatly labeled switches and toggles for elegantly controlling the system. The tool was dazzling.

On the surface of it though, this system is not much more than a framework, although a brilliantly designed one for sure. Once you tear it apart and begin messing with all of its constituent parts however, you find so much more than what you might expect. The documentation points you to every corner of the web and to the finest minds in the field. With the numerous inline comments it delivers all of the theory behind the BEM and OOCSS methodologies. So it’s at this point where I found the tool to be separated from the process of its construction.

In excruciating detail it documents not only how, but also why it was made. This simple tool for developers became a microscope through which it’s possible to analyse a process which has gone mostly unchanged for years.

I often wonder how products, whether physical or digital, can act as more than just tools in the long term. I wonder if they can spread out somehow, becoming useful in the instant that you’re using them and yet simultaneously describe the theories behind their assembly.


Either way, questions about process always lead to more fulfilling answers. They’re more journalistic in nature and, just like we would expect of a great reporter, we want to understand why things happened as much as we want to learn about what has happened. These sorts of questions shed light on why this tool or that particular feature is of use at a given moment in time and why perhaps in the future it might cease to be of use. But process related questions also make us more adaptable to these sorts of problems too.

A tool won’t save us, but the process just might.