You call that DevOps?

Is DevOps the new black?

Mirco Hering
devops cool
Black image via Shutterstock

DevOps is cool. Correction: DevOps is mainstream. Correction: DevOps has broken through the mainstream and is now quickly catching up on “Agile”, “Big Data” and the almighty “Cloud” as an excessively used buzzword. So how much substance is there to the hype of DevOps?

DevOps is everywhere: you can buy DevOps tools from vendors that used to sell ALM tools, you can buy DevOps from cloud vendors who used to sell you virtual infrastructure and you can buy DevOps from consulting companies who used to sell you IT strategies. But how come that on closer inspection a lot of the DevOps practices and tools look eerily familiar to those earlier products they tried to sell you?

I have been working in what used to be called Development Architecture for my entire career – developing IDE extension and compilers in the beginning and later on setting up tooling solutions to support delivery. The reality is that tooling and methodology will only ever be part of the answer. The hard truth is that engineering skills are important in both your DevOps team (yes I dare to call the team by this name, but feel free to call it tools team, platform team, technical service team, system team or by any other name you feel is most appropriate and will offend the least amount of people) and your development and operations teams.

SEE ALSO: DevOps is changing the meaning of the word ‘release’

DevOps is both the best and worst thing that could have happened to people who work in this space. On the one side, all of a sudden the work we do has become sexy. For a long time, looking for labour arbitrage through offshoring or investing in proprietary or commercial off-the-shelf products was the answer to increasing complexity and cost pressure in projects. Good old engineering practices and supporting developers with the right tools was not sexy. Now DevOps is the new black and people want to talk to me about supporting high performance delivery through engineering practices and the right tooling to support developers. Making this important aspect of IT delivery more visible was certainly great.

The dangers of DevOps

But there is the dangerous flipside. All of sudden everyone’s doing it. In my consulting role I spend quite a bit of time performing assessments for clients. And I come across the Dunning-Kruger effect way more often than I expected. For those of you who don’t know about Dunning-Kruger, check it out on Wikipedia – in short it is the common pattern that people who don’t know much about a certain area believe to be better at it than they really are.

In my case the most common symptom of Dunning-Kruger involves Continuous Integration. I walk into an organisation and start working through my assessment framework and I ask the following question: “Do you practice Continuous Integration?” And the answer is “yes we do”. Here I could move on, tick the box for continuous integration and ask for the next practice. In my experience Continuous Integration is actually quite difficult, so I dig a bit deeper “How do you know you are doing Continuous Integration?” the answer “We have Jenkins as our Continuous Integration server.” Okay they use a common tool for CI. One more question I feel will not hurt: “What do you do with Jenkins and how often does it run?” and here Dunning-Kruger hits me: “We run it weekly for our development branch”. Ah yes – here we are again I think. My assessment turns into an education exercise.

Truth be told, I think this is actually what good assessments do, they are an educational tool. For some it is a tool for self-reflection, for others it serves as a helpful guide to have these external discussions with a coach. But all too often, exactly the described contradiction of self-perception “We practice Continuous Integration” and reality “We have a Jenkins server and run it occasionally” leads to people, teams or organisations to say that they are doing DevOps.

Of course I am not free of blame. Using the term DevOps is often a handy shortcut for the large set of practices that underpin DevOps as well as the cultural shift required for it. And when are you allowed to say you are doing DevOps anyway? For me the best way to deal with this is to say that we are on the DevOps journey. And we all are. Everyone who is involved in the delivery of IT solutions is on the DevOps journey. It’s hardly ever a straight line, often people wander off the path or are lost on the way and get further and further away from the goal, but we are all on the DevOps journey to improve IT delivery. Because after all that is what DevOps is all about.

SEE ALSO: Continuous Delivery – putting pressure on your skills, but in a good way

And yes I don’t mind it being the new black and I take the negatives that come with the hype if it means we can have the discussion on improving delivery; not just because it matters to our businesses and clients. But because it makes IT delivery a more humane place to be, it removes stress from people’s lives, it makes us enjoy work more than we used to and it provides all of us in society with better solutions for all our problems, from the mundane (finding a better way to post pictures on Facebook) to the impactful (how to support families in disaster areas with better information through crowdsourcing).

Join me on the journey – it might be a long one, but it’s one where it is worth taking the next step …

Author
Mirco Hering
Mirco has for the last 9 years worked on accelerating software delivery through innovative approaches (what would now be called DevOps) and a few years ago started experimenting with Agile methods. Mirco works for a major consulting and systems integration provider and supports major public and private sector companies in Australia and overseas in their search for efficient IT delivery. He also regularly writes about software deliver, Agile and DevOps on notafactoryanymore.com

Comments
comments powered by Disqus