When is it recommended to adopt a new DevOps tool?

If you’re following me on social media, you’ve seen me publish posts similar to “Added XYZ to my list of projects to check out.” (To let you in on a secret, these posts are auto-generated from my Github stars. Automation is key in marketing as much as in DevOps, you know!) But let’s take a step back for a minute, and ask ourselves: Is it really necessary to constantly check out new tools, and when is the right time to switch to one of them? This is another one of the questions frequently asked during my office hour live streams.

There are multiple contradictory aspects to the question of changing our tool set.

New horizons

First, there’s the learning benefit. I always advocate for curiosity because it’s an effective driver to continuously broaden your horizon, to keep growing. Checking out new tools is an easy way to satisfy that curiosity. After all, new ones are getting released every day. It’s useful to know what’s out there, if only in case you get into a situation in which a certain tool comes in handy. I don’t necessarily try out everything I discover right away because of another aspect that I’ll cover next. But if a tool looks interesting, I’ll at least save a bookmark in my notes so I can retrieve it when the need arises. (I publish these notes on the web, by the way.)

Tools should do work, not create it

That brings me to a downside from which I suffer as much as everyone else: Checking out shiny new things is often more appealing, and most of the time, easier than doing actual work. Have you ever tried a new terminal application, even though your current one is executing your shell commands perfectly fine? A new plugin that solves a problem you perhaps encounter some day? A new editor, even though your current one already has more bells and whistles than a high school marching band? Installed a new desktop environment, a new operating system even, to see how it feels? I have for sure. Guilty on all charges. But let’s be clear here, this is not work. This is a distraction, a leisure time activity. At work, tools are supposed to help us achieve our tasks, not to steal our focus.

When I find myself procrastinating with shiny new objects, I often take a step back and look below the surface, asking myself, “Why am I getting off track here?” Being mindful enough to notice when procrastination hits is a useful skill. Is it because I find this task quite challenging, or on the opposite, a bit boring? Is it because I’m fearing negative feedback? Or am I reluctant to finish this work because of the uncertainty of what’ll come next? There are many reasons that make us susceptible to distraction. Identifying them helps us to break out and getting back on track towards the finish line.

Switching cost

There’s another hidden danger I’d like to warn you about. It’s the cost of switching, which is much higher than just additional disk space taken up. If the new tool is not just a successor or fork of the old one (as with the transition from Vim to Neovim), we’ll have to start from zero in terms of familiarity and muscle memory. Even if the old tool was similar, we probably won’t reap the benefits of the new one without additional effort. I don’t want to go full “sunk cost fallacy” on you, but it’s definitely something you need to consider before leaving for greener pastures.

Greener pastures

Let’s get back to the initial question. When is the right time to try and maybe even adopt new tools? I’d say apply common sense. If you struggle with getting your current task done because of shortcomings of a specific tool, it can make sense to try something else right now. It’s the adage about sharpening the saw. When a woodcutter feels so much pressure that they don’t even take a few minutes out of their day for maintenance, they’re in for a bad time. You need tools that are up for the job, there’s no way around that.

There’s also no way around getting the job done, though! As long as you have everything you need, ignore all those greener pastures, and ship that thing.

Changing it up

That being said, we have to keep up with the times, too, right? So how do we reconcile the need to evaluate alternative, more modern approaches with our responsibility to deliver results? A good way to avoid succumbing to distraction at the wrong time is to give it space in a controlled manner. You know how it is with “all work and no play”. It’s important to give ourselves space to explore, to tinker, to satisfy our curiosity. Why should this principle only apply to children? Setting aside an hour for intentional fiddling every so often might help avoid losing multiple hours to uncontrolled procrastination.

Even if your current tooling is satisfactory, it can be reasonable to upgrade it, provided you are confident that it’ll pay off in a way that benefits your job. One such case is when the new tool will provide you with features that your current one is missing, and —now that’s important— that will enable you to meet your objectives in a more efficient way. For example, getting early feedback from a language server while you’re editing code can improve your efficiency, compared to only finding issues after running tests or triggering a CI pipeline.

Don’t fixate on your tools

Finally, let me take an entirely different viewpoint and tell you that you should not get too attached to your tools in the first place. Focusing too much on tools can be detrimental. For people who aren’t keyboard warriors like us, even deadly.

During their training, firefighters run an obstacle course; first with their gear, then without it. Afterwards, they’re told: “Look, you’re much faster without your tools.” What sounds silly and obvious is actually a critical psychological lesson. You see, mastering the handling and application of their tools is an essential part of a firefighter’s job. They become an extension of their bodies. Throughout history, this had the unintended consequence that firefighters died in unexpected situations because they kept doing what was their expertise: using their tools. The right thing to do, however, would have been to drop their gear and run. Because that option didn’t even cross their mind, they perished. Their belief in the power of their tools led them astray. They didn’t realize that the usual approach wasn’t valid any longer. That’s why modern training methods teach them that a firefighter without tools is still a firefighter, and hopefully, one who lives to experience their retirement.

Next time you’re confronted with a problem for which you can’t find a solution using your familiar tools, consider if there’s an approach that doesn’t involve them. An engineer without their DevOps tools is still an engineer. Maybe even more so.