Picking the right tools without hating yourself afterward

Picking the right tool does not guarantee success but picking the wrong one certainly makes it way more difficult. External libraries, plug-ins, and tools, in general, serves some purposes but at a different grade of efficiency depending on many factors.

Some good-sounded phrases like “the more, the better” are just wrong when it comes to selecting the tools that will help to construct and maintain projects and their products. Here are some considerations for peace of mind (or not) when it comes to decision time.

How a good tool looks like

It should solve a specific set or class of problems, hopefully without creating new ones. A tool can be an abstract thing such as methodologies, a concrete but not physical like software, and objects with mass for which no examples are required.

Some tools define a framework where different pieces interact. For example, coding IDEs (Integrated Development Environment) are becoming the most flexible frameworks where the referred pieces can be retrieved from both free and paid marketplaces, and available plug-ins enhance the capabilities.

A tool may not last forever, and that’s OK

It’s easy —and self-evident— to understand that the time-passage and even its simplest usage affects them. That’s not generally the case for computer hardware, which becomes obsolete not because of its wear but because the software and operations they perform are eagerly demanding more and more.

Slow and gradual changes go unnoticed to most people until the shift surpasses some threshold or starts to feel just odd. Context evolution does not necessarily imply improvements or deterioration but only change. Improvements seem to require a greater degree of change than deterioration to get noticed, maybe just because that’s the way humans are wired.

What can change? The physical state of the tool, the problem that the tool is tackling, the expected outcome, the available resources, and we can keep adding nuances of many sorts.

As the context evolves and the specifications changes tools need to be reassessed. Some tools discarded in a previous selection can now fit better than the ones actually in use.

What to consider when evaluating tools

Gathering more information than needed is not bad on its own. The analysis paralysis is not due to an immense amount of raw data nor that of the extracted information, but because those who interpret them are not sure enough about the goals, or the process is flawed. Some basic questions and aspects allow making a “quick” comparison and discard some obvious bad prospects.

Is it widely used and is there a community making questions and suggestions on different platforms? Even when a tool seems to be the optimal one for some specific needs we have, it can easily become a pebble (and then a rock) on our shoes. Addressing these two questions guarantees nothing, but makes it more probable that if obstacles arrive they will be sorted.

Actively evolving tools include the risk of divergence between how we use them now and their updated set of features in a time to come. That’s why tools need to be reassessed from time to time, and that is preferable over a resting state which in turn is doomed to obsolescence.

Support and compatibility come easy to mind, but thinking in the long run, they are really the consequence of what was said before. A non-widely-used tool that is not actively evolving and has no community of users can hardly keep the support and compatibility. Even if there is such a tool, a user will notice that the compatibility tends to narrow and collateral problems to spread. If no actions are taken the project heads down the road of being driven by the limitation of the used tools, goes into a lockdown by external restrictions, and be forced to choose only among bad solutions.

Downsides are to be considered as well but need to be scaled properly. Considering future possible scenarios and uses of the tool is a known trap-door that leads to the mentioned paralysis and reminds of the no-free-lunch theorem (brief not-fully-technical explanation) that roughly states that no tool can excel in every scenario compared to all other tools.

Independent from the reasons why a tool was picked in the past, as things evolve there may be a time when replacement is required. The exit strategies can be seen as insurance options, what to do when the time comes. Lacking a way out leads to be more dependant than needed on external factors, to lose control.

Constructing the perfect toolbox

There is no universal toolbox perfect for every single situation.

Selecting tools comes after defining the problem to solve, and not before. It can happen that some unknown aspects went unaware during the selection process, and that’s fine until question marks start to stack or get bold. As the cues add up, it becomes obvious that the problem’s definition needs to be revisited and improved; the missing information can be blocking moving forward without hopelessly risking wasting all sort of resources.

Human feelings like sentimentalism, ego, negation, and so on, can make maintaining a healthy toolbox a lot harder than it needs. It is extremely improbable for a toolbox to be highly effective in too many scenarios with different characteristics.

As a bottom-line, toolboxes are dynamic and it’s content ever-evolving. Noting small changes (e.g. requirements, performance, external conditions) is a keystone in triggering a new assessment of the tools it contains.