9 Reasons DevOps Is A Dirty Word
DevOps means a massive change for most organizations and requires serious commitment from management and workers. It isn't for everyone, but is it really for anyone? Here are nine reasons DevOps might not be right for you and your organization.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/bltf9d5459500ba3dee/64cb42378ebff572e382cd5b/Slide1_Intro_DevOps_anathomy_iStock_97165909_LARGE.png?width=700&auto=webp&quality=80&disable=upscale)
Everyone wants to be on the cutting edge of operational productivity. When organizations develop new and better ways of doing things, it's natural for them to spread throughout the industry. Once in a while, though, the new way of doing things is terrible.
If you want to get a good fistfight started, it's hard to do better than throwing out a challenge to someone's chosen methods for developing software and running the IT department. When you can slap someone with a challenge to both of those in one word, then you're setting up a barbed wire cage match.
[See Agile vs. DevOps: 10 Ways They're Different.]
DevOps is one of the hottest trends in software development and IT operations. It combines software development, application deployment, and IT operations in a more or less seamless stream of IT goodness and bliss.
I've written about some keys to successful DevOps and some of the tools that can help you win at DevOps. But there has to be another side to the argument, so I went looking for those who don't like DevOps at all.
While I didn't find a quadrant of the internet crawling with DevOps haters -- this isn't politics, after all -- I did find quite a few people who were skeptics or DevOps antagonists. I combed through many of those blog posts and articles to pull together some of the more common reasons for saying that DevOps is a rotten methodology that no sane organization should attempt.
Here's something to keep in mind: Among DevOps fans and opponents, I haven't run across anyone who says that DevOps should be embraced by absolutely every organization out there.
It works well for some. It's an uncomfortable fit for others. It would be an utter disaster for a third group. Some of the horror stories come from companies in the third group that have strained mightily to make DevOps work, so keep context in mind.
Having put these anti-DevOps rationales out into the world, I'm curious to hear your take. Have I expressed something that you think but haven't put into writing? Am I preaching to the choir, here? Or is this article proof that I've finally lost my mind? Let me know here or on Twitter, and we'll continue the conversation -- whether or not we continue the move to DevOps.
For DevOps to work, two functional groups of professionals have to come together in a single functional team. The members of each of those teams have to concentrate on their own work while also paying close attention (and giving deep consideration) to the work of the other. That's a tough sell to the group members and a difficult management trick to pull off. For reasons ranging from temperament and culture to training and tool expertise, software developers and operations professionals don't make natural teammates. Trying to turn them into a single team is a recipe for frustration and failure.
Today's enterprise IT department must manage a host of very complex tasks, each of which must be performed to the highest level of professional competence. No reasonable person should expect people to be expert in every job -- and the idea that time taken away from one's area of expertise is the most productive use of staff effort is at best counter-intuitive. Silos get developed because specialization is very effective at applying the best expertise and highest functionality for each job. Unless you want to make do with a uniform level of mediocrity across your organization, leave your silos alone.
DevOps tends to rest on the assumption that everyone in the organization is equally skilled and proficient at their job. That's a lovely egalitarian vision, but it's not often reflected by real-world experience. The fact is that any group of humans is likely to have individuals of varying levels of skill and talent. In DevOps, those differences are going to be the source of tensions, strains, and, ultimately, points of failure. More traditional methodologies, such as waterfall development, were created to take these skill discrepancies into account and correct for them in the testing and deployment processes. There are no participation trophies in enterprise IT. Don't pretend that everyone is equally skilled.
Whenever you see a discussion of DevOps you'll find a significant part of the conversation turns on the tools everyone on the team is using. The importance of the tools, how the tools have an impact on the processes, how happy everyone is now that the amazing tools are part of their lives, and similar topics are common in the DevOps discussion.
Here's the thing, though: No matter how good the tools are, there are issues that they just can't overcome. Remember the section on varying skill levels? Tools won't even everything out. Tools can't turn bad administrators into good administrators or mediocre developers into superstars. Tools help, but too many DevOps roll-outs pretend that tools are the solution to every problem. They aren't.
DevOps gives equal weight to both sides of the equation, development and operations. That's charming, but it fails to take into account that, for most organizations most of the time, the two are anything but equal. When you try to manage the two sides of the equation as though there were an equals sign between them, you're going to end up shortchanging one function in favor of its weaker sibling. When so much of management is about developing centers of excellence, do you really want to be handicapping your excellent team in this critical area?
DevOps has a great premise and offers a great promise. In fact, that promise may be so great that disappointment is almost inevitable. In a world that sees so many executives working to manage the expectations of their internal business partners and the executive committee, is there a real advantage to taking on a methodology that has disappointment built in? Business life is hard enough -- IT should look for methodologies that minimize failure, not create more failure potential.
One of the core principles of DevOps is that you're constantly developing, deploying, maintaining, and iterating on your applications. It sounds so very cool and is precisely what happens in the App Store for various mobile platforms, but we're not talking about consumer apps here. We're talking about a mission-critical enterprise application set. When you're constantly iterating on that, you're trying to change out major portions of the application while the enterprise is still in motion. It's possible to do that, but it's not easy and not pretty. Unless you're a fan of tightrope-walking without a net, think hard about whether you really need this kind of drama in your life.
Have you noticed how emotional people can get about DevOps? Some people truly love the idea, but if you bring it up in many organizations you'll find a crowd with torches and pitchforks outside your office door. Is your company somehow lacking in ideas that will divide your department and make people less likely to work together? I didn't think so. Change is hard in the best of circumstances. When the change comes in accompanied by a label as emotionally charged as DevOps, then it's going to have to bring benefits that are highly unlikely in order to justify the grief.
There are executive committees that are stalwart and true, using nothing but time-tested principles to guide the organization. Then there are the panic-stricken executive committees flitting from buzzword to buzzword in search of the secret to higher productivity, lower costs, and a beefier bottom line. If you're unlucky enough to work under one of the latter, then the last thing you need to do is introduce the concept of DevOps to the proceedings. The result is certain to be mangled responsibilities, mashed up lines of communication, and expectations that a combined team of Avengers and X-Men in full coding and operational-excellence modes could not fulfill.
So, did I cover all the points? Are you now so frightened by the idea of DevOps that you're going to have a waterfall tattooed somewhere on your person? If so, then I've done a service, since you're likely not convinced that DevOps is the way forward for your organization. If, on the other hand, you've squared your shoulders and are now more determined than ever to succeed with DevOps, then I'll accept your thanks as well, because you'll likely succeed.
DevOps isn't easy. It's a massive change for most organizations and requires serious commitment from management and hands-on workers alike. I'd be interested to know what you think of my list -- what ideas you think are overblown and what ones you think I've missed. Let me know, and we'll continue the discussion on the evils of DevOps in the comments, below.
There are executive committees that are stalwart and true, using nothing but time-tested principles to guide the organization. Then there are the panic-stricken executive committees flitting from buzzword to buzzword in search of the secret to higher productivity, lower costs, and a beefier bottom line. If you're unlucky enough to work under one of the latter, then the last thing you need to do is introduce the concept of DevOps to the proceedings. The result is certain to be mangled responsibilities, mashed up lines of communication, and expectations that a combined team of Avengers and X-Men in full coding and operational-excellence modes could not fulfill.
So, did I cover all the points? Are you now so frightened by the idea of DevOps that you're going to have a waterfall tattooed somewhere on your person? If so, then I've done a service, since you're likely not convinced that DevOps is the way forward for your organization. If, on the other hand, you've squared your shoulders and are now more determined than ever to succeed with DevOps, then I'll accept your thanks as well, because you'll likely succeed.
DevOps isn't easy. It's a massive change for most organizations and requires serious commitment from management and hands-on workers alike. I'd be interested to know what you think of my list -- what ideas you think are overblown and what ones you think I've missed. Let me know, and we'll continue the discussion on the evils of DevOps in the comments, below.
-
About the Author(s)
You May Also Like