As an engineer, you already have enough responsibilities when developing software. Adding more tasks–say, DevOps-related ones—to your workday activities might not sound very appealing. With DevOps, not only are you responsible for producing working software, but now you also need to automate the building, testing, and deployment phases of the software. That’s a lot to take care of! But the extra work aside, maybe you’re just tired of the DevOps movement, and all the hype surrounding it is causing DevOps fatigue.
As a former developer, I can identify with that feeling of fatigue. I’ve also seen some colleagues reach a certain level of frustration with DevOps. There are times when we make the mistake of taking on everything, even the releases. This is especially common if we’re perfectionists and don’t like to deliver software with bugs. We could even get to the point of releasing our code to production. (Although now that you’re “doing” DevOps, that might become your responsibility anyway.) After all, if we code it, we know the things that could go wrong and how to fix it if there are problems.
Even though now I’m more on the operations side of things—dealing with servers and helping companies implement DevOps—let me share some thoughts with you about why I think engineers are getting DevOps fatigue.
Working More but Getting the Same Pay
DevOps has stopped being perceived as only for developers and operators. But the downside of that is that some organizations are moving the DevOps functions to the developers. Developers might now feel they’re being forced to take care of the delivery pipeline after they’ve finished their work. It’s already hard enough for them to try to create software without bugs! More likely than not, developers are getting frustrated because they’re making the same wages with more (and a different type of) work.
As I said before, there are times when developers feel the need to be doing more than they should. For example, if operations folks take too much time to answer their questions and requests, developers will always find a way to solve any problem themselves. They’re even willing to learn new things like cloud and infrastructure-as-code. A lot of things happen when a developer finishes their code and it’s ready to be shipped to production. At that point, it’s not just about building and then copy/pasting artifacts. Deployments and releases could be more complicated, and one team can’t handle everything.
I don’t see developers going the extra mile as a bad thing. But there are times when these new responsibilities are being taken for granted. And that’s where the problem with DevOps lies for engineers.
Experiencing Consequences From Losing Specialization
Even though engineers are still programming and DevOps fosters treating the infrastructure as code, engineers now need to learn about infrastructure. It’s no easy task to provision and configure a server without wasting resources. Sure, software engineers need to make sure their code doesn’t generate memory leaks and doesn’t make excessive use of threads or networking. But the knowledge developers will need to handle those tasks is not enough to justify calling them experts on infrastructure.
Having to properly scale the application and operate the infrastructure could take some time to get right. There are so many things that operation folks need to consider, such as if servers are running on-prem or in a cloud or hybrid environment. It would be a lie to say that having a Chef recipe, Terraform template, or Ansible playbook is enough. It’s better if the organization has a subject matter expert to make the most of the infrastructure and optimize costs. Nothing beats experience.
Again, it’s not a bad thing that developers know more about infrastructure and how their code affects production systems. But some developers like creating application code. Developers might feel like DevOps is de-specializing them because of all the other things they need to take care of to release software.
DevOps practices and tools are continually growing and evolving, and the same goes for developers’ fields. It’s always good to work with subject matter experts because when those weird problems appear…who you gonna call? Certainly not the Ghostbusters.
Hearing Everyone Talk About DevOps
“Everyone is doing DevOps, and so should you.” I’m sure you’ve heard the message.
I do believe that DevOps outcomes are great, but only when you’ve previously identified a problem where DevOps was a good fit for the solution. If you’re just implementing DevOps because it’s the new trend, you’re probably just fine with your current delivery pipeline. It’s not a good idea—especially with DevOps—to try to replicate what worked for others; everyone has different needs and problems.
I like the way Gene Kim has defined DevOps, but I’ll only quote a sentence that’s relevant to this post—I don’t want to contribute to your fatigue. He said that “DevOps is not about what you do, but what your outcomes are.” If DevOps is about what your outcomes are instead of what you do, it doesn’t make any sense to adopt DevOps. You might be already doing some DevOps things and haven’t noticed yet.
If you’re just tired of all DevOps stuff, that’s fine. I get that fatigue once in a while too. In my case, it’s because people have an incorrect understanding of DevOps, which causes them to implement things that the DevOps movement was started to fix—things like creating another silo by having a separate team or adding the “full stack” title to everyone, which creates the idea that everyone needs to know about everything.
Getting More Pressure to Deliver Quickly
Another way that people are getting DevOps wrong is by setting the expectation that because they’re “doing” DevOps now, the organization should be doing several deployments per day. It takes time to change things. DevOps implies a change in the culture, and changing a culture becomes harder when the organization is large. It’s wrong to think that you’ll be able to deliver faster overnight. There are so many things you need to take care of. Some examples are automated build and tests, production-like environments, configuration management, and so on.
There are a lot of unrealistic expectations with DevOps, and several deployments per day are one of them. Not surprisingly, many people started to hear about this when John Allspaw and Paul Hammond from Flickr talked about doing ten deployments per day at a conference. The 2017 state of DevOps report also reinforces the idea that high performers (companies like Amazon, Netflix, Google, and other “unicorns”) do several deployments per day.
All of that is appealing, so I understand why some organizations would like to “do” DevOps. But to succeed you first need to identify where your problems are. There are tremendous benefits from doing several deployments per day, but it’s not easy to get it right. I wrote a post on this a while back.
You shouldn’t give yourself X months to be DevOps compliant and deliver faster. Engineers already have enough pressure to meet the deadlines, and adding more expectations doesn’t do any good.
Outcomes Are What Matters
Let me repeat Gene’s quote one more time. “DevOps is not about what you do, but what your outcomes are.” When you embrace this idea, you start realizing that many of the things you think about DevOps don’t make sense. Shifting activities to the left in your delivery pipeline doesn’t mean that developers will now take care of everything or that operations folks will program new features in the system. Every piece in the puzzle has its purpose, and forcing people to add tasks outside of the scope of their duties to their workload is never a good practice.
Engineers might get tired with DevOps because they end up doing more work. Sure, they’re learning new things, but they’re also being de-specialized in their field. Or maybe management is adding more pressure with unrealistic expectations, not realizing that change doesn’t happen overnight. But it’s also possible that engineers have just had enough of hearing everyone talking about DevOps.
If you or your team is getting DevOps fatigue, forget about it for a moment. Identify where you’re having problems when pushing your code changes to production. Reasons vary, but your process, tools, or even your people could be preventing you from releasing software effortlessly. The idea behind DevOps is not bad; the problem is that everyone has a different definition of DevOps and implements it in different ways, and that’s frustrating.
