My occasional reminder that “Change is good, but predictability is better,” is in the form of a message to DevOps upper management. I thought it would be fun to write, and would offer a different perspective and drive than normal. Hope you enjoy!
Dear Management,
Too much of anything is bad. No matter the topic, once too much of it is present, problems crop up. That is just as true in DevOps as any other topic.
We need some level of standardization, because too many different toolchains is bad. If there is a tool learning curve before team A can assist team B, we are not taking advantage of standardization. In fact, we’re creating a well of technical debt that someone is going to have to clean out. Are we really going to maintain separate toolchains for each project on top of the variety of languages and targets we already have to manage? For years? Is that the most productive use of our time? Do we even have an exit plan to replace that dying open source project that is the core of one of our apps?
So let’s do some level of standardization on toolchains, shall we? That is the most stable route to standardized tests and easy-to-troubleshoot environments.
But let’s not get too standardized, either. Because too much of anything is bad, and too much standardization is stagnation.
We have never seen an environment nor talked to peers and heard them say, “Oh yeaaahh, our environment is perfect! We made everything work smoothly, and all metrics are headed in the right direction while development and deployment have gotten easier.” Those people don’t exist, because in our age of near-constant change, those environments don’t exist.
In spite of standardization, we need to keep trying new tools, options, environments and policies to increase our quality and deliverability. Give a team the OK to ignore standard X and bring in something they think is better suited to their needs; then see if you can adopt it more widely.
In short, we want standardization to make our jobs easier, but we don’t want stagnation. We don’t need fifty languages, twenty CI tools, and half a dozen security scanners. We need a few good ones, and the ability to look around at new products/ideas in the space to find better ones.
In fact, that app that no one is allowed to mess with? Let’s rewrite it, so it is newer and more maintainable; and, while we’re at it, let’s try some of these new and different products and processes. After all, we’re biting the bullet re-writing, we may as well take the extra step, and we might find something useful to the broader collection of DevOps teams.
And trust us when we tell you a tool or process is the right fit. Ninety percent of the time, the buzzword of the day that you saw on Twitter is either not ready for production yet, or is already in use at our org. It’s our job, so we’re paying attention. And buzzwords are marketing lingo aimed at you, to force us into using something we’ve already looked at.
You’re doing a good job, we just think we could be doing better. Give us standards, along with room to challenge them a bit. Of course some of us won’t be happy when our tool isn’t the one chosen to standardize on, but we’ll pull together in the end, if you remind us that we’re working to put the org on a more stable and maintainable footing.
Thank you,
More of your DevOps employees than you think.
