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 written) 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 true:
- 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 included)
- “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 for reading.
