How to Choose a Tool

In a post cleverly and imperfectly titled, "The Worst Tool for the Job," statistician John Cook discusses, the "advantages of not using the best tool for the job." Here is the broad point:

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...

Image by Igor Figueredo, via Unsplash, license.

And the savings will also include time, which works similarly to money here.

Time savings obviously comes into play with time not spent researching the best available tools before obtaining that adequate tool. But there's a subtler point, which a commenter brings up that applies for cases when you know you'll need the tool (or something like it) more than once. On top of being able to get started faster, the adequate tool allows your to learn what you actually need:

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. [format edits, bold added]

There is no way, particularly when doing something new, to anticipate every requirement of the job or to know what your best work flow will look like. The adequate tool will indeed let you get to work faster, but it can also lead to saving lots of time and money down the road. Cook's example was of a simple diagram he made for a client, using a simple tool.

He named a well-known tool as possibly the "best" for the job, but it's possible a simpler tool than that would be better for his particular use case, because of cost (assuming he doesn't need every feature of the more common tool), ease-of use, or some other reason.

It's easy to want to "get it right the first time" and it can be fun to research tools. But sometimes, ignorance stands in the way of the perfect start many of us like to imagine. And there can be satisfaction in finding a good tool few know about, or that is much better for a purpose than the answer that even people in the know might give.

-- CAV