By Kyle Prawel, Cloud and DevOps Architect, Logicworks

“The fact that some choice is good doesn’t necessarily mean that more choice is better.” 
― Barry Schwartz, The Paradox of Choice: Why More Is Less

There are hundreds of tools, services, and platforms available to support the development lifecycle, and millions of possible ways to construct a secure and productive CI/CD pipeline. 

However, all these choices aren’t necessarily healthy for focused DevOps teams. In this post, I’ll discuss why DevOps teams often get distracted by tool choice rather than focusing on what really matters: shipping code to users, consistently delivering value. 

Choosing the ‘Best’ Tools May Be Impossible

When reviewing the Cloud and DevOps Tools Landscape, maintained by the Cloud Native Computing Foundation (CNCF), it’s easy to see how toolset choices for teams are getting out of hand.

So how do engineers even begin to choose the best set of tools? After all, what does ‘best’ even mean?  Differences in maturity, selected platforms, and opinions of stakeholders and developers might even make selection near impossible. 

But that doesn’t stop us from having favorites, arguing with other engineers about our favorites, and constantly tweaking our unique patchwork of tools. We come back from conferences enamored with minor tool improvements and start new arguments with our colleagues. Further, because of the real labor involved in setting up integrations between the different tools, organizations are wasting time swapping components. 

We love technology, and appreciate this wrestling match of tool-vs-tool, but we must remember that ‘velocity in value delivery’ is our duty, and the tech we chatter about is a distraction to our purpose.

I can already hear friends and colleagues: “But Kyle, the right tool for the job saves time and money, so tool selection is important.”  This is true, but how do we ensure that the benefits of the tools we select aren’t outweighed by the inefficient way we choose and argue about them? I’m not talking about using the end of a wrench as a hammer (which I’m sure we’ve all done in a pinch), I’m talking about selecting between a hammer with a wood or fiberglass handle. Both do the job, and while they are different, we’d all agree it would be unproductive to stop work, take a vote to throw out the wooden handled hammers, go to the store to buy fiberglass ones, spend the rest of the day debating about red or blue colored versions, and the rest of the week implementing them on the jobsite. 

This is where we are with many DevOps toolsets: more focused on preferences than quantitative evidence towards a tools’ productivity gains. 

Why is Choice a Dangerous Thing?

To be fair, extensive choice itself is not the problem; it’s our human nature in evaluating the choice that leads to problematic behavior. It’s ok, it’s forgivable, we simply need to be mindful of this and adapt accordingly. 

Humans are strongly driven by a phenomenon called ‘Fear Of Missing Out’ (FOMO). We’re afraid that a selection might be wrong, and that the choices others are making may be better, even when the choice is inconsequential. Because of FOMO, we are likely to suffer from escalated expectations and postdecision regrets. When there are so many options, we assume one of them must be perfect, and we set unreasonable expectations for our selection process, the tool itself, and then assume we did it wrong post-selection because the tool didn’t turn out to be perfect. 

Our psychology makes us believe that perfection exists, and that therefore we must seek it out. All of those speakers at conferences have figured push-button deploys with sixteen tools in 0.2 nanoseconds and look so happy and fulfilled — what are we doing wrong?!?

How to Actually Select DevOps Tools

To solve this, first recognize that these traits are inherent to your team, and adapt your selection process accordingly. Remove emotion and brand preferences from the decision process, and then collectively build selection criteria based on quantitative evidence towards a tools’ productivity gains. 

In practical terms, it’s usually smart to start with off-the-shelf (OTS) tools that fulfill 85% of a team’s needs. Even better if you can find a full product suite that covers nearly every stage of the deployment process, so that there’s native integration between different stages of tools and a single dashboard to view everything. 

The value of more generic OTS integrated products usually outweighs the marginal value of specialized features in a disparate tool. This is especially true when you add into the calculations labor toiling to choose, integrate, maintain, and rechoose a perpetually changing field of tools. Providing a team instant/easy/no-code implementations of DevOps pipelines leads to immediate production and value generation. 

This is why I’m a fan of cloud-native services like the AWS DevOps suite and Azure DevOps. Built on the popularity of Visual Studio Team Services (VSTS), Azure DevOps provides most of what is important to DevOps teams without the need to ‘reconceptualize’ what the technology footprint looks like to support CI/CD or digging through the pile of individual tools. You don’t have to worry about making the tools work together or managing the underlying infrastructure. Azure DevOps also lets you integrate other tools as you need, so the future isn’t set in stone. Without major financial or technological lock-in, teams can add/replace functionality with new toolsets as data suggests productivity could be improved.

Once the requirement of the hammer is clearly defined and initial value has been shipped to your customer, then the team can start defining the decision metrics around wood versus fiberglass. But you may never need to worry about getting it 100% right. Worst case is you all keep using hammers, pounding out work (no pun intended). FOMO was avoided, labor waste reduced, and value shipped.

Note: Overtime, if an engineer can’t make a quantitative case for a change in tooling, then it is ignored, no matter how cool the swag was at the vendor’s booth. 

Summary

If you have a custom set of DevOps tools that works for you, then more power to you. Here at Logicworks, we’ve worked with nearly every DevOps tool under the sun. We’ve watched our clients see huge efficiency gains out of these tools, and also have seen companies get lost in the swamps of tool selection. If you want help navigating these difficult waters, contact us. 

In part two of this exploration into expediting shipping code, we’ll discuss using the OTS CI/CD offering that is Azure DevOps. We’ll share how to achieve the ‘let’s just get started’ capabilities of the platform, and what to keep in mind as you grow into it, avoiding potential pitfalls and rework along the way.  

Kyle is a certified Cloud and DevOps architect, as well as digital transformation evangelist dedicated to seeing people and organizations perform at their best.  Hailing originally from healthcare IT and high compliance environments, Kyle is a creative problem solver, eager to match technology solutions to real-world challenges.