Treating tools different when they are support tooling

Why do we in the IT industry seem to treat support tooling like the ugly cousin?

First I’d like to stress the above are my opinions. And only me sharing my thoughts with the readers of this post.

I thought I’d share my thoughts when seeing how some people in the industry are approaching what I like to call ‘Support tooling’. Which in my opinion seems to have become the sometimes remembered cousin of Primary Tooling.

Before I go on, I would like to explain what I mean by these 2 types of tooling.
The way I see it, there are tools we use to do work, and there are tools we use that help us do work.

• Tools we use to do work with are things like: IDE,Source code repository, image editing, data storage, tools that are required for us to get a system or application working and to production
• Support tooling are things that are meant to help us do our job: Wiki’s, Project dash-boarding, Communication, Deployment tooling. Anything that isn't required to get a system out to production.

What makes us choose a tool?

Tools we work with to get the job done (Primary tools)

When it comes to tooling we require to do our work, we will scrutinize the tool, and find the best for the job that fits the project and our own working ideals. And we are always looking for something that can make our life easier. Test this by walking into a room of developers and declare that a particular editor is the best, pick any one: vim,emacs,idea,visual studio,mono develop,etc…
I can almost assure you, the ‘conversation’ will go on, and on. With at least half the developers saying something like “I used to use x, but then I found y, best upgrade I've made”

What makes a tool so much better than another?

The long and short of it is the context of the tool being used. There are some tick boxes we are running in our head when looking at any tooling. I’ve started calling it the Tool Choice Life Cycle. They are items we all know and use without needing to be taught. And it doesn't just fit into IT, it spans through life

1. Does it offer what we need
2. Is it within budget
3. Is it fast enough / easy enough to use
4. How many times will I curse this tool verses the others (this one isn’t everyone)
5. Does it fit my process, or a process I want to get to?
6. Once we have the tool, we would normally keep our eyes open for tools that fit our need better than the current, and decide if we should ‘upgrade’ (I use this word rather loosely here)

Tools that are just there to help (Support tooling)

It feels like sometimes when it comes to Support tooling, we treat it like the ugly duckling in the family of tooling. While falling into so many traps.

Traps of support tooling

Time Scales allocated to finding these tools

From my experience it seems to me some think that looking for a tool that fits an actual need, is a loss of time, and so a tool is found that sort of ticks the boxes. And the search is stopped.

We forget that if we take an extra 5 days to find a tool now that fits us well, it is less time lost than a team of 10 people taking 5 minutes longer for a process for 5 months.

This means, if the tool is used for more than 5 months on a team on 10 people general processing would be just 5 minutes faster during the day, you are losing more time than you would have spent finding a system better suited to your needs to begin with, don’t believe me?

With that yes, the 5 days is a bulk investment, over the 5 months, but what happens after 2 years? Now we’re quickly coming up on an entire month that is lost jointly across the team.

Because it fits someone else, it must fit me

In my view, no. This is the same as saying because 2 people have the same shirt size, they should both use the same design.

Here are some differences that I feel could mean that the system being used by someone else, might not be the best option for the needs of another:

• How are documents stored
• How often are documents read
• Where does the average user need to connect from
• How many projects are running
• What is the end goal
• Does it fit the process already in play, or a process you would like to have
• Team composition
• Methodology used
• Bulk of users (maybe for the other person/company, it’s outward facing for transparency, and for yourself it’s mostly for capturing data, that is hardly read)

The Person choosing the system is not the main user

If you are getting a system that should be used by project managers, don’t make a developer choose the system. This is obvious right? If it is, then why do we sometimes have managers choosing systems that makes reporting easy for them, but the bulk of the usage comes from the IT department, where time is lost because of a given tool? Why do we not rather find a way to have the IT Department flowing easily, and get a second tool for the reporting, which may only take up 10% of the tools total usage.

I feel we should be finding who uses the system the most, and work out a net time lost. If you would humour me for for a moment, If given 2 tools we will call them tools one and two.

If this tool is destined to straddle 2 departments.

• One— Department A would jointly gain 3 hours a month, and Department B would jointly lose 5 hours a month.
• Two— Department A would lose 1 hour a month, and Department B would gain 2 hours a month
• The net time of this tool is One : -2 hours, Two: +1 hour

When Drawn like this it makes perfect sense which tool should be used (unless Department A’s time is more precious than B’s which can happen). But lets throw in a third tool, that works off the data driven by tool Two, and formats it in a way that now causes Department A to gain time as well. Well that would be a win, right?

But from what I've seen over time, is that generally we seem to ignore the ‘time lost’ idea, and rather only look at what is gained. So in this case, tool One wins. Why? Because tool one saves a department 3 hours, while tool Two only saves a department 2 hours. There will be no time allocated to find a way if we can work with more than one, and more often than not, the time that would be lost, is not considered until someone complains why something is taking so long, by which time it’s normally too late.

Integration, Integration Everywhere

Integration between tools has become the next best thing since multi-core processing, and lets be honest, for good reason. But sometimes sometimes I think we need to step back and take a look at what this integration offers. Do I really need these tools to integrate? Sometimes I think the answer comes back a rather large no. Different circumstances will require different levels of integration.

An example of this (I promise the only one). Do I really need my PM to know every commit to the feature branch? Should I not rather just have my pm connected to my burn down chart?

Depending on your need this could be an answer of Yes I need it or No I don’t. Sometimes there is another way to attack the problem.

I also feel we need to keep aware that every integration we add to a given system, we only lock ourselves in further. I've seen people tell me how they strongly dislike using a given tool. When asked why they still use it, they say something along the lines of: Most of our tool stack would need to be replaced.

Tools that integrate have become a dime a dozen. It is so easy to solve a problem we face now with an integration. But what happens when one of those systems are no longer required, the increased price is out of budget, or there is a better system out there? Are we able to move easily?

Now I am sure people are reading this thinking, You sir have no clue, integration is powerful, are you really suggesting to not integrate?? Short answer is no, but know what you getting into. Treat an integration like it is in a sense a third tool.

Contentedness settles like morning dew

We all know this, but it’s to fall into this trap. Sometimes you can go for months before even realising you have fallen on. But rest assured, everyone falls into it.

You start off with a tool that is just meant to help you for now. Just to get passed this path. And before you know it you are years down the line, still using the same tool that fits to a degree. But people have become so used to the weird caveats of this tool where you have to align your process with the tool, that it has just become the tool that is use.

This is the point where for primary tools we are always looking for better. But I feel like this gets forgotten when using support tooling, why? Is it because it affects more people? Is it because it integrates with other tools, and we would need to upgrade much more than just this tool? Is it because we only use the tooling for 2–10 hours in a week, and don’t want to shake the boat? Maybe there just isn't anything out there that solves your need? Or is, what I feel is it the more likely option, the people using the system have gotten so used to it, that doing the extra work to have this tool work for you has become part of the job.

Single Point of Failure

When I talk about single point of failure I'm not talking in terms of systems, where if a small piece gives away your system falls apart. I'm talking about when we get so entrenched in a stack created by a third party. For the most part these third party stacks don’t integrate well with other stacks, For obvious business reasons. I'm not going to say don’t use these stacks, 9/10 they are the better option. But I feel like sometimes we use another tool on the stack, because it almost fits what we need, or what we think we need at that moment. Sometimes there is a tool out there that fits exactly what you actually need, and can integrate with your stack, and normally many other tools as well. What happens when that stack you have is surpassed by another, is too expensive, or just doesn't fit your need any more? Do I have to suck it up and pay the new price, or spend months finding and moving to other tooling?

Once again, I'm not going to say don’t invest in a stack. I think there is great benefit in a stack. One throat to choke, Support, user experience across tools. But I feel like those are not always reasons to stay on a stack when the users of the tool can benefit using a different tool, or have more integration available on another tool.

Final thoughts

I am not saying anyone’s tool set-up is bad. A small team dealing mostly with support tickets has a very different use case for tools than a large team managing multiple products and concurrent feature development, which is very different to the needs of a solo contractor.

I feel like support tooling, which is made to help you, support you, and fit into your process, seems to in some instances be picked for the wrong reasons, and in some cases can become more of a hindrance for some of the people that use them the most.