The myth of the right tool for the job

The phrase “the right tool for the job” is one we’ve all heard in software development and we’ve all most likely said it at some point. However when you stop and think about what such a phrase actually means you begin to realise it’s actually quite a problematic one, it makes too many assumptions. One could also go as far to say it has the potential to be quite a detrimental way to justify the use of a tool over other alternatives.

This post aims to take a look at what those five seemingly innocent words really mean, and hopefully by the end of this post you’ll possibly reconsider using it in future, or at the very least be a little more conscious about its use.

Making assumptions in a world of variability

Often when you hear the aforementioned phrase used it’s usually in the context of making an assertion or justification for the most suitable framework, language or service to be used in a given project. The problem with this is it makes too many assumptions. It’s rare anyone truly knows the full scope and nature of a project upfront until it’s done. You may have read the ten page project specification, or know the domain well, but ask yourself this - how many times have you been working on a project only to have the scope or specification changed underneath you. No one can predict the future, so why use a language that implies unquestionable certainty.

Ultimately building software is about making the right trade offs given the various different constraints and conditions (risks, costs, time to name a few), there are no “right” or “wrong” solutions, just ones that make the appropriate trade offs, this also applies to our tooling.

I’ll leave you with this great tweet from John Allspaw:

"The right tool for the job!" said someone whose assumptions, past experience, motivations, and definition of "job" aren‘t explicit.

— John Allspaw (@allspaw) March 18, 2015