We’ve been at this for a few years now, talking about DevOps & what it
means to be a DevOps friendly (or insert your term here) organization.
For much of this time I’ve held the belief that an organization could
change & that by creating examples of awesomeness you could lead a horse
to water. Largely, I still think this is true, I still think in an
organization absent of examples of what works – creating awesomeness can
help people see that something better might be possible.
In tandem with this I’ve watched (and
countless discussions about what DevOps means. I’ve heard countless
definitions of what people think DevOps means which differ from my own
definition. I’ve watched organizations create entirely new teams
centered around what they understand DevOps to be. The typical charter
of these teams centers around working with developers, yes, but also
around automation & tooling.
In this process the word/title/team name of “DevOps” has become
synonymous with “Operationally focused Development”… or Ops folks who
code (sometimes). To me, this is just Operations and Development, but
I’m an open minded guy and this post isn’t really about that – if doing
this is so different from what you believe Operations is that you need
to call it something different, so be it.
For organizations which I observe to be actually embracing the sprit of
DevOps as it was originally intended, I find a few things that seem
- Behavior isn’t isolated to Dev & Ops, it happens across the company
and is usually promoted as part of the company core values.
- Behavior is a result of the whole, everyone contributes to making it
work and ensuring that it continues to work. They hire (and fire) with
this value in mind.
- Behavior happens because the people involved see it as a means to an
end, that working together is how we achieve greatness & no single
team can do that.
- They don’t usually call it DevOps.
Why does that last bullet matter? Because giving it a name doesn’t make
it so. Actually giving it a name, I think, removes power from the teams
to define how things should work. We already have names for this stuff:
Collaboration, Communication, Teamwork. When you call it “DevOps” then I
start to wonder what you mean, because it must be different from
something I already have a name for.
So today I heard a reference to Cargo Cult,
decided to lookup this term I’ve used in the past to make sure I was
using it correctly, and was struck by how it applies so perfectly to
what I see as wrong with the way many folks interpret DevOps.
We’ve seen examples of Cargo Cult in the past. Agile implementations are
surely ripe with examples of companies implementing a process but not
embracing the principles. The world of marketing uses the idea every day to
sell you stuff you don’t need:
- “Installing this IDS will make you more secure” (security engineer not
- “Using Adobe Photoshop will make you produce awesome photos” (ability
to use a camera not included)
- “Buying these jeans will make you look like a movie star” (gym
membership, nutritionist, open-schedule definitely not included)
The result you are trying to reproduce is embodied in something that is
a subset of what actually produced it. Taking that subset and dropping
it into your life doesn’t give you all the things that produced it, you
get an empty shell of the thing.
I love to rock climb and spend a fair amount of time at it. Rock
Climbers have some observable characteristics – strong hands & upper
body, relatively good balance, maybe less sanity than most folks. Many
folks first approach climbing thinking that strength is the primary
barrier to improvement. They think that to be a good climber they have
to get strong. Then you watch some massive muscle-bound gym rat try to
climb and you realize that can’t be right.
The reality is that climbers get strong by climbing. Climbers climb
because they love the challenge, and they get better by being persistent
and having the mental discipline to overcome doubt and fear. You can’t
watch a climber and see passion, fear, doubt and their response to it.
You can’t read their thoughts and know that, despite that move looking
incredibly easy for them, it required very precise movement and
exceptional focus and attention. You may not realize that the reason
that particular sequence of movements worked for them was because they
are 5’10” and have unusually long arms.
Climbers may enjoy the strength benefits of climbing, but if their
objective was to become strong, there are more direct means. They become
good climbers because they love something more fundamental about it.
In organizations where DevOps works, it isn’t Developers working with
Operations that make it work, it’s people wanting to work with other
people and the organization encouraging them to find the right solution
together that makes it work. Operations seems to work well with
Development in these organizations, an observable outcome of the
culture, but reproducing that practice in another company isn’t likely
to produce the same results. I’d go so far as to say it’s guaranteed to
not produce the expected results.
I wrote a long winded post
about what I see as things leading to a functional software development
organization. DevOps is not a practice within these things that is
singularly important, nor is it a team which is relevant to success.
It’s now become a distracting misnomer for a subset of observable traits
in successful organizations, few of which contribute to overall success
when practiced in isolation. The factors that do contribute to success
have been defined for quite a while now, they were defined in Good to
Great, they are described in The Phoenix Project, and to a large extent
they are at the core of what Agile was intended to be.
If you Cargo Cult DevOps into your organization then you’re just
implementing a subset of what successful companies do & you are bound
not to see the results you expect, unless your expectations are low.
On the other hand, if your goal is to use it as a hiring tool to clarify
to Ops folks that the job you are offering is working on automation, I
get it, but wish there was another term for that – because it isn’t
DevOps. It’s Operations, or Development, or both. Something we all
should be doing anyways.
I’m not really sure this post helps anyone, but it helped me – so thanks