The worst tool for the job

I don’t recall where I read this, but someone recommended that if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford. (Update: Thanks to Jordi for reminding me in the comments that this comes from Kevin Kelly.)

If you follow this strategy, you’ll sometimes waste a little money by buying a cheap tool before buying a good one. But you won’t waste money buying expensive tools that you rarely use. And you won’t waste money by buying a sequence of incrementally better tools until you finally buy a good one.

The advice above was given in the context of tools you’d find in a hardware store, but I’ve been thinking about it in the context of software tools. There’s something to be said for having crude tools that are convenient for small tasks, and sophisticated tools that are appropriate for big tasks, but not investing much in the middle. That’s kind of what I was getting at in my recent post From shell to system.

I’m making a bunch of diagrams for a new project, and the best tool for the job would probably be Adobe Illustrator because professionals routinely use it to make high-quality vector art. But I’m not doing that. I’m drawing ASCII art diagrams, just boxes and arrows drawn in plain text. Something like the drawing below.

  +--------------+ compiles to +---+  
  | Foo language | ----------> | C |  
  +--------------+             +---+  
         | embeds into
    | Bar DSL |

The crude nature of ASCII art is a feature, not a bug. There is no temptation to be precious [*] about the aesthetics since the end product isn’t going to win any design awards in any case. There are compelling incentives to keep the diagrams small and simple. It encourages keeping the focus on content and give up on aesthetics once you hit diminishing return, which occurs fairly quickly.

Drawing ASCII diagrams is clumsy, even with tools that make it easier. Wouldn’t it be faster to use a tool meant for drawing? Well, yes and no. Drawing individual graphic elements would be faster in a drawing tool. But inevitably I’d spend more time on the appearance of the graphs, and so ultimately it would be slower.

The initial motivation for making ASCII diagrams was to keep diagrams and source code in the same file, not to eliminate the temptation to spend too much time tweaking graphics. The latter was a positive unintended consequence.

Related post: Doing good work with bad tools


I’m not doing this completely bare-knuckles. Emacs has tools like artist-mode that make it easier than manually positioning every character. And I’m using  DITAA sometimes to compile the plain text diagrams into graphics more appropriate for pasting into a report. The example above compiles to the image below.

DITAA example

More on how this works here.


[*] Not precious as in valuable, but precious as in affectedly or excessively refined. As in filmmaker Darren Doane’s slogan “We are not precious here.”

10 thoughts on “The worst tool for the job

  1. Yes! I totally agree with this. Both for regular tools (I’m not a carpenter, so I have a big collection of old poor quality tools, but they get the job done.) and for software tools. I’m always crafting up ugly perl just to get something done.

    Regarding drawing, I’ve become a huge fan of yuml ( It’s essentially an easier (and much simplified) syntax for dot in graphviz. The thing I love about it is that you get no control over layout and very little control over formatting so you don’t waste any time there. The other benefit is that since you have no control over layout, if it creates a nice layout, then that’s a sign that your concept is right, if it can’t figure out how to render your ideas, then maybe you’re just not thinking right.,%20%5BFoo%20Language%5D-compiles%20to%3E%5BC%5D

  2. Great choice for creating diagrams. ASCII diagrams and graphviz/dot are awesome.

    Illustrator and other vector drawing tools lowered the cost/time of production for a certain type of illustration. For drawing diagrams, the cost/time of production it’s still too expensive (pencil and paper is far cheaper).

    However, *good* diagramming tools lower the cost/time of production for diagrams by a substantial amount.

    I’m a fan of since it lowers the cost/time to produce a diagram to a few hours *at most* and to a few minutes at least. It makes it fast enough to draw diagrams that it’s a surprise that they aren’t used in every single pull request and patch submission.

  3. The advice on the cheapest tool is by Kevin Kelly in his 62 bits of unsolicited advice.

  4. Also look at (previously known as Free, scriptable. Just a happy user.

  5. The other advantage of this route is that your requirements will become more clear with a subpar tool.

    If I buy the subpar tool and use it, it may not meet all my needs. In some cases, these may be needs I did not know I had until I had a tool to build the thing I needed. In this case, the cheap tool helped me define my requirements and helped me learn about what I *really* need from the object I am building.

    Now I am much better equipped to go and buy the correct tool I need.

  6. Edvard Majakari

    PlantUML is even better; ignore the name, I’m not that strict about UML, but it makes updating relations much, much more simple, as you basically just write a (di)graph with things like

    user -> frontend
    frontend -> api
    api -> redis
    api -> db

    and let PlantUML (and Graphviz) worry about layout

  7. I highly encourage you to check out Excalidraw ( ). It’s a fantastically minimalist in-browser drawing editor that produces diagrams rendered as if they were drawn by hand.
    The analog, hand drawn style of the rendering has a magnificent side effect of encouraging the mind to focus on the content, without getting distracted by irrelevant details of the drawing itself.
    Best of all, this tool is a gem of a bootstrapped open source effort with many contributors; the tool didn’t exist at all until an enterprising hacker started it around Christmas holidays this past year. Worth a look!

Comments are closed.