This post is a part of How To Ship Maintainable Product series

Tools are a substantial part of building software. Wisely chosen help to reduce development time. The product quality improves as well. Nowadays software is so complex, that it is impossible to build something from scratch. Teams need to choose various tools to meet deadlines.

Tooling includes IDE, frameworks, platforms, engines, databases, protocols and all other elements the team has to choose from to build a product.

Right tools for the job

The most important thing in choosing the tool is to understand what problem needs to be solved. First, the problem needs to be understood and a suitable tool selected after. A suitable tool can be described as one which is capable to solve the problem with little effort. It is also extendable to a certain degree to meet more complex scenarios.

One suit all trap

Development teams sometimes fall into procrastination trap when it comes to tools selection. They are lead by the right purpose of sticking to things proved working in the past. Unfortunately, very often tools are used in the wrong context just because we do not know any alternatives. We should remember, that IT industry changes rapidly and yesterday best practices can be tomorrow technical debt.

”When you know how to use a hammer, everything looks like a nail”

Tool maturity

Choosing new tools can give us a competitive advantage, because of the innovative approaches and ways of solving problems. On the other side, new tools are usually barely tested in production. Additionally, the future development and support are unknown. We may end up supporting the tool on our own because it is so deeply embedded in our product already.

Mature and widely used tools are more stable. The community around them has tested various scenarios and incrementally improved weaknesses and errors. Most of the times behind such tools there is a large organisation or community. For example Android (Google) or .NET Framework (Microsoft).

Learning curve

Another perspective we need to look at is the ‘learning curve’. We may have chosen a very robust tool, but it will take some time to master it. Our cost/benefit analysis should prove that it is essential to use the selected tool. Otherwise, we will end up in an unmaintainable beast, that nobody wants to extend or support.

Documentation, examples, workshops and all other resources provided by vendor or community play a very important role in the learning process.

Worth mentioning here is also developers enthusiasm during the learning process. It will drop very fast if developers hit the wall over and over again.

Licencing

From the business point of view, we should check licencing terms of the chosen tools. Sometimes it may be against company policy. Building a closed source operating system based on GPL licenced product is probably not a good idea. Some tools are free for commercial use until we hit some limit like a number of employees, annual revenue or number of messages send in the system. Licence terms should be revisited prior to final decision.

Own tools

One of the issues we have in software development is a tendency to reinvent the wheel. We do it over and over again. Before taking a decision to create own tool I would advise to conduct a deep search on the internet. Usually, somebody met the same problem in the past.

If we finally decide to build own tool we should think about it as a another code base to support. It will help us solve problems of course, but we will need to maintain it in the future (document, fix bugs, etc). I observe development teams falling into this trap very often. They forget about that extra code that has to be rewritten along with business features.

Summary

Tooling is important. Wisely chosen tools decrease the development time extremally. Tools created for a different purpose will only make problems and extend work. Be aware of licencing and decisions on building own tools.