Why should you buy software tools?

Should you buy software tools?

There is a fine line between being frugal with your software tools and tolerating low quality software. Just because software can be written in a simple text editor and compiled with a free compiler begs the question: why pay for software tools at all? If a programmer can debug and fix problems by re-running the code, tweaking and re-running it again why not just let them do it?

Many companies see software tools as developers just indulging themselves with toys rather than what they can be: huge productivity boosts. Developers with the right set of tools can find and fix difficult bugs rapidly. Developers without the right tools might never fix the problem, and just work around it for years.

Software companies – which is nearly everyone these days – are inundated with new tools and techniques to help them ship more software, faster. Most companies have two default reactions to this: either adopt as many tools as possible; or, adopt almost none because it’s cheaper or easier just to stick to what they know.

But what’s the optimal route for choosing your tools? How do you evaluate software tools in a more constructive way?

The key is to ask the right questions. Here are some of the best ways of evaluating whether a tool is useful for your business.

Step 1: Establish how you’re currently solving problems

Software tools provide smooth automation in place of manual tasks or cobbled together scripts.

When looking at a software tool, first ask: what  do we do at the moment? Many software tools fill a gap which is currently filled in manually, or with cobbled together scripts or which is not done at all.

These manual or scripted tasks might be configuring servers (for example, chef, puppet), writing your own UI frameworks (QT, React), logging and debugging (New Relic, Undo) and or many other areas.

When you look at how you’re currently solving the problem you can do a quick estimate of the cost of engineers, support staff, sales and the cost to your customers. With this in mind, imagine you had that all that time available for any other project. That’s what the tool can give you – the ability to focus on work which actually matters.

Step 2: Do the cost-benefit analysis

The cost of learning and onboarding a new tool, which has to account for training time, bedding into the team process and integration with your infrastructure all needs to be compared to the potential gains. The potential time that the tool can give you provides a very quick idea of the cost of not buying a tool to fix the problem, but often this is done very late in the process. This is why it’s worth doing the maths upfront. If you know that you’re talking about a $100k problem (cost) which will give you a potential $500k in revenue (sales) by freeing up your engineers, the wider business will take the problem more seriously.

Step 3: Don’t believe Marketing. Just try it.

Making a purchase as a result of being taken in hook, line and sinker by marketing blurbs is bad in the best of cases, but is often meaningless in software because how it works, and how it integrates with your environment is key. Choosing software tools are like choosing anything practical – you need to see it, try it and learn how to work with it to know if it will be of use.

Evaluating software in the abstract leads to one of two bad decisions: making a decision because the software has a feature, but the exact implementation of the feature is unclear; not making a decision because you haven’t seen the subtle magic inside the product.

The lesson here is to put the tool through its paces on a real problem, much like you’d interview a highly skilled candidate. Throw problems at the tool, find out what it’s good at and how it’s going to fit into your team.

Step 4: Think about how to make the tool part of your pipeline

Software systems should work together as closely as possible, ideally seamlessly as part of your coding workflow. Coding pipelines should see one tool hand over to the next, creating a seamless flow of new code and features. IDEs and programming environments are now customisable enough to integrate tools closely, avoiding the need for engineers to learn (and forget) new tools, increasing the chance that they’ll know and use the tool.

So make sure that the tool is part of the working environment and isn’t going to live separately, confusing people and ultimately ending up being forgotten..

Step 5: Make it part of the development process

Practices like test-driven development require a different mindset rather than just a new tool, so you need to factor in how this becomes part of your development culture, not just part of the development environment.

Using a user interface package will only benefit your team if the thinking behind it is properly understood and the framework is integrated into your software. Data storage solutions can be abused more easily than they can be used properly. Debugging tools can sit idle if no one owns the process of understanding what they can do.

Make sure the tool has immediate usage, and becomes used by engineers from day one so they can learn the problems it solves and when to use it.

—-

So why haven’t we done this already?

Sometimes decisions to adopt new tools can seem obvious in hindsight, so ask yourself: why haven’t we adopted this tool already? This question can provoke reasons around this not being a priority, which probably will turn out to be a mixture of reasons such as nobody knew exactly what was needed or somebody was waiting for a decision to be made on another matter, and many other reasons… which often aren’t good.

Companies can often live without a tool for months or years because of a lack of understanding that such tools exist on the market or because it’s become habit to go with the status quo. Equally bad is when companies purchase new tools which end up languishing in the ‘toolbox’  because team leaders failed to communicate the value of a tool to the team and no incentives were setup for developers to use them.

Communicate effectively with your team

If you’re going to make a difference to your team and bring in tools that should help your business, you need to make sure that your team knows that such tools exist and are given the right incentives to use them. This may take many forms (e.g. running training sessions, pointing devs to the relevant documentation etc.) but it is fundamentally down to ownership and should be the responsibility of effective team leaders to ensure that their team can get onboarded as quickly and effortlessly as possible.

In sum, new tools may be one solution to achieving software quality. Try them, estimate the ROI you’ll get from them and ensure you have the right processes in place to make them work for your business.