The DevOps person and a 300 meter marathon
There are some concepts that have a logical conflict built in, self contradictions. A marathon is 42,195 meters, otherwise it is not a marathon, so a 300 meter marathon can not exist. You can not have a diet plan for intuitive eating, a vegan slaughterhouse or cooked raw food. Democratic processes with a predefined result is as intrinsically incoherent as an environment friendly coal mine, regardless of what people say. It makes no sense to beatify Martin Luther, since one of the things that made him thrown out of church is saying that everyone is a saint, and no one is a saint. I believe that the DevOps person (or team) is as bad as Saint Luther.
The point of DevOps is that the responsibility for development, operations and maintenance of an application, should be on the same team. Everyone does DevOps, and no one does DevOps. It is a way of working that eliminates the hand-offs by saying that writing and running the code is part of the same job.
To enable DevOps there are a lot of tools for things like continuous delivery. The tools themselves are sometimes confused with DevOps as a concept. But you can use all of them without getting the benefits of DevOps. Likewise, no cloud service, containerisation tool or build system is needed to do DevOps. Everything that is needed is in the statement “Everyone is both a developer and does operations.” (The separation is not to be compared with Luther’s saint vs. sinner as more than a conceptual similarity.)
It is dangerous to believe DevOps to be either a role, a team or a toolset. One of the effects might be to overlook the changes needed in the Dev part of DevOps. In the DORA DevOps report automated tests, trunk based development and loosely coupled architecture is listed next to deployment automation and cloud (page 31 is my favourite). Writing tests, using version control systems and design code is clearly a dev thing. Those skills are as important as setting up a build pipeline or containers that run in the cloud. If you just take a team of developers, and add someone who knows the toolchain for DevOps, you might oversee the need for training in other technical skills, such as TDD.
Another trap is that if you still have one person in the team responsible for getting the code into production, and taking care of the new shiny tools, not much have changed. You have only created a mini ops team within the dev team. The end goal is about shared responsibility and a holistic view on the lifecycle of a feature, and that needs to include everyone.
So the next time someone talks about DevOps as a person, a role, a team or a tool chain, remember your favourite self contradiction. I will think about Saint Luther doing a diet plan for intuitive eating.
ps
If you find any examples I have not listed, please share them in the comments or on Twitter @edytterbrink. If anyone comes up with a nice hashtag I will edit and add it here.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about DevOps to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.