About Aaron Nichols

Aaron works with startups and small companies to help their development organizations move faster. He is presently the senior Operations Engineer at a startup in Boulder working on implementation of Continuous Deployment, automated monitoring & configuration management.

Cargo Cult: Devops

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.
 

Reference: Cargo Cult: Devops from our JCG partner Aaron Nichols at the Operation Bootstrap blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


three × 3 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close