Choosing the Right Tools for the Job
The saying “If all you have is a hammer, everything looks like a nail” summarizes a cognitive bias we have to use tools that are most familiar to us, even if they are the wrong tools for the job.
In the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, authors Brown, Malveau, McCormick, and Mowbray apply this bias to software professionals, as we often fall into this trap. As any craftsman will tell you, choosing the right tool for the job is essential for getting the job done right, and software development is no different.
Here are some tips on how to choose the right tools for use on your projects.
Match Tools to Your Process
The first thing that gets us in trouble with tools is when we attempt to change our processes to conform to how a tool works. In general it is much easier to learn how to use a new tool than to get people to change a process they are familiar with. Plus, unless your process is already broken, changing a process for the sake of a new tool will often result in your having a bigger problem: dealing with a tool you aren’t familiar with while trying to use it in a new process.
As an example, some code-scanning tools provide in-depth analysis but run for a long time to collect these detailed results. Other scanning tools provide more lightweight, incremental results much faster. If you are seeking to integrate code scanning into your continuous integration process, the latter is going to be a better fit for your process. However, if your software must go through an extensive security audit prior to release, the former tool is going to meet this business objective.
Seek Tools That Have Some Familiar Aspects
Even if you are not familiar with a particular tool, often tools leverage aspects of technology we are familiar with, and this can ease adoption. If adopting a new tool means you must get other roles or teams in your organization to adopt it too, familiarity will help smooth this transition.
For instance, tools that automate your builds, tests, or environment provisioning all use some kind of scripting or programming language. Choosing a tool that uses a language your team or organization already knows will help ease tool adoption.
Experiment with Tools before Committing to Them
When trying to decide if a tool is right for you, nothing beats actually using it. Would you purchase a car without a test drive? Buy a house without walking through it and imagining how you would live there?
While it may reduce your team’s productivity in the near term, take the time to test out each tool you are considering to see how well it fits your purpose. And like a good test drive for a car, explore all aspects of a tool before choosing it.
