Is the DevOps the new black?

(This article was first published in the JAXmagazine)

jaxenterDevOps 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� How come that on close 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 all my
career � developing IDE extension and compilers in the beginning and later on
setting up tooling solutions to support delivery. 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 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 people) and your development and operations teams.

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 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.

But� there is the dangerous flipside. All of sudden everyone is 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
(https://en.wikipedia.org/wiki/Dunning�Kruger_effect) � 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
occassionally� leads to people, teams or organisations saying 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. Its 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. And yes I don�t mind it being the new black and I take the
negatives that come from the hype if it means we can have the discussion on
improving delivery; not just because it matters to our businesses and clients.
Because it makes IT delivery a more humane place to be, it removes stress from
people�s life, it makes you enjoy work more than it used to and it provides all of
us in society with better solutions for all our problems from the mundane (how to
better post pictures on Facebook for example) to the impactful (how to support
families in disaster areas with better information through crowdsourcing for
example.)

Join me on the journey, it might be a long one, but one that is worth taking the
next step on�