Unless you are either very new or have no connection to the software delivery profession and industry (in which case I’d be curious to hear how you found this blog post), you have probably heard of “DevOps”. DevOps is “the union of people, processes, and products, to enable continuous delivery of value to our end users.” What this actually means for developers, delivery teams, and organizations is often not very clear. But everyone says you have to do it, so it has got to be good, right?
Below are 10 reasons that implementing a DevOps transformation might not be a good idea for you:
1. It’s okay; you know what you’re doing
It says it right there in the formal definition of DevOps: DevOps is about enabling delivery of value to our end users. That might be great for some teams, but you don’t need that kind of distraction. You know exactly what you need to build – the project plan is very clear about it. Besides, your end users will use whatever you build for them. They are users in the end; that’s what they do: use.
2. With DevOps you must continuously deliver
Again, it says it right there in the definition: “…enable continuous delivery of value…” You have enough trouble as it is with your semi-annual releases; imagine how tough it would be to have to do that multiple times a day! Sure, if you release every few weeks, let alone every day, your releases would be simpler and smaller, but don’t they always say that size doesn’t matter, and that it is the thought that counts? Well, thinking about continuous delivery is scary, and that’s that.
3. DevOps destabilizes corporate structure
From a practical standpoint, DevOps is about having software developers collaborate with operations engineers, and that just won’t do. Your organization is set up in silos; you even have developers and ops folks in different buildings, just to make sure that they don’t start giving ideas to each other. Give them an inch, and they will start conspiring together – operations engineers will make requests for making the product more operable, and developers might get operations to help them deliver more frequently, and you just established how scary that is!
4. Automation upsets the workforce
A core aspect of DevOps is the extensive use of automation to build, deploy, and test the software. If you allow development teams to set up automated build pipelines, what are the build masters going to do? If you shift all of your tests from manual to automated unit tests what are you going to do with your QA engineers? If you automate your deployments, let alone the creation of test and production environments, what are your operations engineers going to do?!?
Sure, automated tests cannot replace manual tests completely, and there will always be important exploratory tests for QA engineers to execute. Of course your operations engineers have a lot of work to do, just keeping the production site up and running, but you cannot take the chance, can you?
5. DevOps makes you deliver faster
One of the outcomes of adopting DevOps practices is that teams can deliver software to production faster than before, or in business terms: faster time to market. Not so fast! Haste makes waste, after all, and you don’t want to create waste, do you? Besides, if you somehow manage to deliver faster than the competition, you might be forced to innovate, rather than follow other organizations down a well-known path. Besides, you might not even be a consumer facing organization, and there might not be any competition. Your users will just have to accept that this is how you roll.
It’s not like if your leadership decides that you are not delivering fast enough, they might decide to outsource your work to a software firm that can move faster. Right..?
6. Constant feedback can be confusing
The early and continuous feedback that is a big part of DevOps deliveries can be overwhelming. Whether it is from stakeholders at a sprint review, or input from your product’s telemetry, that your developers enabled the operations engineers to gather and analyze, the feedback might surprise you as to what your users are doing with the software you delivered, and might indicate that you should invest more time further developing features that you thought were fine as they are, or worse, might suggest that you cease efforts in developing a feature that you have planned to develop for another three or four weeks. Either way, this feedback might disagree with the plan that you spent months putting together before a single line of code was written. That can be very upsetting! What should you do in that case? Just ignore the plan?!? Not plan so much in the first place?!? What???
7. Production telemetry helps detect defects
As if it is not bad enough that operations engineers use production telemetry to try to influence what the product does by suggesting changes to the plan, they also use it to detect defects! This completely violates the DRY principle (Don’t Repeat Yourself)! You already have testers and a QA team that are supposed to find all of the defects in the product. If telemetry uncovers any problems that you didn’t already know about, it could make you look bad, right?
Sure, if you have build, test, and deployment automation in place, you could possibly fix the problem before the users begin to complain, but you already decided that automation is not a good fit for your organization.
8. Autonomous engineering is scary
DevOps teams take responsibility for the entire software delivery process, from development to production. DevOps teams operate with a high level of autonomy, and that is scary! How can you know what the developers are doing if they are not going through all of the bureaucratic tape that your organization put in place to inhibit excessive productivity and effectiveness?
Of course, modern tooling can ensure that engineers are not doing things that they are not supposed to do, but you cannot trust computer systems to consistently apply your policies. Besides, if the teams can simply do whatever is needed to deliver software effectively, without your say so, what will your job become?!?
9. DevOps promotes engagement
DevOps teams are known to be happier, more engaged, and better motivated than their less autonomous counterparts, and we cannot have that. You pay your engineering teams to deliver features, not to be happy!
10. DevOps teams are more effective
DevOps practices enable teams to be more efficient and reduce costs associated with organizational waste… Hmm… perhaps that means that you can lay off some people and do more with less..?
Grade your self…
Count how many of these arguments seem like a good reason to avoid implementing a DevOps transformation in your organization. If you scored more than zero, you might want to think about the value proposition – enabling continuous delivery of value to you end users. If customer satisfaction is important to your business, it might be worth the effort.
If you think otherwise, say so in the comments – let’s have a chat!
Summary
Despite the sarcastic tone of this post, every single one of these points describes one of the virtues of DevOps, and how adopting its principles and practices can help your organization. I hope you see the value.
Cheers,
Assaf
