Three Things I Ask of a Good Tool

It should be light. It should keep its word. It should be quiet.

I started building tools for a living, and it gave me a habit. When something I use annoys me, I follow the annoyance all the way down to find out where it comes from. After a few years of following, my standard for choosing a tool came down to three lines. It should be light. It should keep its word. It should be quiet.

First, it should be light.

Software is a strange industry. Every other branch of engineering evolves toward doing the same job with less material. Software alone runs backwards. A notepad eats hundreds of megabytes. A chat app outweighs a video game. Each new version makes the feature list longer and the tool duller. The app that once opened instantly now makes you wait for it to boot.

Aircraft designers have a saying. Perfection is reached not when there is nothing left to add, but when there is nothing left to take away. When a thing has to fly, every gram is expensive, so they cut with real urgency. In software, weight looks free, so nobody cuts. But the weight is not free. It is paid for every day, a little at a time, out of the user's memory, battery, and waiting.

Adding a feature takes skill. Removing one takes courage. The feature you add becomes something to brag about, and the feature you remove goes unnoticed by everyone. Still, I am of the school that believes the quality of a tool is mostly decided by what was taken out.

Second, it should keep its word.

A tool can betray you in many ways. One day you find yourself logged out of everything. A feature you relied on moves up to a higher pricing tier. Something that worked yesterday stops working after today's update. The forms differ, but they share one thing. The user changed nothing, and the tool changed its promise.

Follow the roots of these betrayals and you usually find dependence. If a tool cannot take a single step without its company's server, then its lifespan and its character are decided not by the quality of the tool but by the circumstances of that company. When the pricing strategy changes, the tool changes. When the company stumbles, the tool stumbles. You thought you bought a tool. It turns out you were subscribing to a company's decision-making.

So I favor designs that reduce dependence. A tool that is complete inside your own computer will, to put it plainly, keep working even if the company that made it disappears tomorrow. There are promises that can only be made on top of that structure. I want the things I build to be on the side that can make those promises.

Third, it should be quiet.

A good tool is forgotten while you use it. Cooking with a sharp knife, you do not think about the knife. You think about the food. The moments a tool forces itself into your thoughts are mostly the moments it is misbehaving. Software that nags you to update, interrupts you with notifications, and pops up asking you to admire its new feature has stuck a straw into a working person's attention.

Attention is the most expensive resource of this era, and strangely it gets treated as free. The cost of an interruption is not the few seconds it takes. It is the minutes it takes to reconnect the flow it cut. So among a tool's virtues I rank "absence of presence" quite high. Do the job, get out of sight, and do not step forward until called.

---

Writing the three down, I find they are one sentence. A good tool does not take the user's time. Not by weight, not by betrayal, not by noise.

The app I am building right now downloads as 4 megabytes and unpacks to 14. A few seconds to download, one breath to open. Keeping those numbers has often been harder than adding another feature. I intend to keep them anyway. The longest promise a toolmaker can make turns out to be the simplest one.