DevOps tools today increasingly are no longer out-of-the-box ready for use. And that’s an aggravating issue
Imagine you bought a new power tool—a sweet battery-powered drill/screwdriver that did everything you needed.
Imagine it looked as though it ran on its own, but when you got it out of the box, you discovered that it didn’t come with a battery.
Imagine you got the battery, and only after the battery was installed you discovered that it needed a specialized wrench/chuck to install and remove bits. And you had to go buy that.
Imagine you got the chuck and were all set to go, only to discover that it would slip and normal drill bits wouldn’t turn unless you had a specialized adapter.
That’s what our tools environment in DevOps has become. And we need to demand better.
If your software requires X and Y and Z to be useful—whether you are commercial or open source, whether X and Y and Z are a million bucks or zero—state it before install.
We’re setting up an entirely new environment, stretching things a bit for an internal project, and honestly, the amount of “Oh yeah, this is required, too” that we’re finding out after install is insane. We have done our research; we should not be getting surprised by “But wait! There’s more!” type installs.
For an industry that insists on plug-and-play for all OSes and every odd bit of hardware ever dreamed up, we sure let software steamroll us. Vendors need to be clear about what will be required to run the tool and what will be required to run it effectively before we waste our time. Because there are some dependencies we’re not willing to accept, for usability reasons and/or security reasons. And if, under the covers, the tool does exactly the same thing as another tool … then what, exactly, is the value-add? It better be good.
We’re just one DevOps group—and a small one at that—but we have decided for this project not to use tools that dupe us into thinking they’re usable out of the box, then immediately require us to install something else. Or at least we’re trying. This has gotten so prevalent that in a couple of areas, we’re struggling. After all, the software still has to be built.
It’s a good thing drill manufacturers don’t think that way. Maybe there is hope.
Meanwhile, we’ll keep trying to do what you all are doing: kicking rear and keeping systems running.
