The right tool is the one people can use

There’s a tendency in open source projects — and the tech sector more broadly — to focus on using (or building) the exactly-right tool for the job. Sometimes that’s truly important. Many times, though, the wrong tool can do an okay-enough job. If a tool is a means to an end (and it is!), then the right tool is the one that gets the job done. Even if it wasn’t intended for that purpose.

When I was early in my career, I spent a lot of time helping graduate students print posters for conferences that they had designed in PowerPoint. This often went poorly. Layouts that looked fine on screen would have subtle errors when printed. This waste of time and supplies was annoying, but how much time would have been spent teaching all of them to use another tool (that the department would likely have had to pay for) so they could print one or two posters a year?

As I’ve matured, I’ve come to appreciate the fact that people use the “wrong” tool not out of malice — or even ignorance — but because it’s good enough to do the job at hand. The difference between a tool that’s “good enough” and a tool that’s “perfect” often requires far more effort than can be justified.

In general, if existing software does a “good enough” job, you shouldn’t write or procure more. You add complexity and/or maintenance burden for little return. I wrote this in 2021 and my opinion hasn’t changed. Wait until you know that the existing tool is unworkable (not just imperfect) before trying to “solve” it. And this means, to the greatest extent you can, you should let your contributors and users work with whatever tool makes most sense to them.

This post’s featured photo by Ben Cotton.