It’s the rare team that doesn’t need to change something about its processes or tooling. The limits of a tool may lead us to realize that we are not working as effectively as we can, and often, changing a tool is part of the solution. But there are good and bad ways to select a tool and how you use it. In particular there are risks when you focus first on tools before considering the problem.
There are many reasons you might start with tools, some valid, some not. Constraints such as cost or existing licensing arrangements might limit your choices. Starting with tools is also a good way to feel like you are making concrete progress.
But be mindful of making decisions based on hype. A popular tool, or one endorsed or developed by a successful company, is worth a look for many reasons, but it’s important to consider whether the tool actually fits your needs. Some oft-mentioned tools are useful if you are working on the same problems as other companies, but you may not be.
Like other technical choices, the risk associated with tool selection can be mitigated by experiments, but a successful experiment depends on having the right evaluation criteria. A good way to understand your problem and requirements is to think about your current process and the process you want to have. You can then evaluate how well a proposed tool supports the new process.
This sounds obvious, but teams often assume that they have a clear understanding of their problem and don’t challenge that assumption. Sometimes a brief analysis of the problem may lead to a simpler solution than you thought. Sometimes even doing nothing may be the right approach.
Being inflexible with your process is another risk. You may find a tool that is close to what you need but which does not do things exactly as you wish. In these cases you may be tempted to extend the tool in some nonstandard way. If the tool is widely used to solve a fairly standard problem, it can be worthwhile to reconsider your approach—your problem may not be as unique as you think. Blindly extending or adapting a tool to fit your nonstandard needs can lead to extra work and, eventually, avoidable tech debt.
There are many possible inputs into your decision making process. The key to a successful decision is to ground it in the technical, process, and business needs of your application, rather than hype or unsupported assumptions. Examine whether you can fit your process into the idioms your tool supports instead of adding complexity. If you find yourself making many customizations, consider whether your problem really is that different from others.
By starting with your process goals first, you can do a better job of evaluating and selecting tools. This will lead to better decisions and, in the end, lower costs.
