The Problem with Defining DevOps

Posted by Jon Hendren

Defining DevOps - ScriptRock

There's an old idea in Hollywood— if you can't pitch an idea in one sentence, it's too complicated. The term "DevOps" is about 5 years old, and the community still has no consensus on what that word really means, even though it's full of thought leaders who'll claim to be able to tell you.
A recent blog post went into detail about the lack of a widely agreed-upon definition and the search for one at the recent DevOps State of the Union. You can read it the whole thing here, but the basic idea is that participants actively tried to come up with a simple definition, and couldn't. One definition was given, some guys from Netflix disagreed, and the author followed up with:

"I threw out my definition that I believed that DevOps really was just the increased probability that an organization is going to find product / market fit with their solution."

What does that mean? None of these words actually say anything. If you boil it way down, it comes out to something like: "DevOps... is good?"

Clearly, the concept of DevOps has a marketing problem, and it's making the hurdle to entry for new participants in the DevOps community needlessly high.

Let's do a quick thought experiment. Say you've been coding at some small shop off the beaten path for the last several years. Not a lot has changed as far as your job in that time, but one afternoon, your boss calls you into their office and says, "I've been seeing resumes with the word 'DevOps'. Figure out what that is and whether or not we need it." Maybe you've seen the word around too, but never looked into it.

You'd probably start by googling it, and trudging through dozens of blogs that all offer competing definitions which are clouded by buzzwords, doublespeak, and reckless hyperbole. It's often a difficult read, and even harder to comprehend. This has the effect of making DevOps culture— if you want to call it that— nearly impenetrable to new blood. Not only is it tricky to find a simple definition or explanation, it is actually unpleasant to do so.

DevOps bloggers, with their own series of experiences and ideas, like to insert their own views and call it that definition of DevOps. Perhaps one blogger's definition will insist automation is the silver bullet, while another insists that DevOps is mostly a mindset. One may provide a strict list of software to use and practices to be performed. Another still will tell you that DevOps is spiritual— which should be your cue that we've entered quack territory.

The core of DevOps is not a difficult or complex concept. More or less, it's the idea that developers and operations should collaborate more closely than they traditionally have, so neither side is caught with their pants down when something blows up.

That's it. Of course, there are additional ideas floating around this community that are helpful. Some of the more specific practices they recommend can be incredibly useful. Automation is powerful. A cultural shift is a big deal. But no single blogger has a reasonable explanation that fits the bill for everyone across the board.

Heider-Simmel DemonstrationHumor me for a moment— There's an old experiment called the Heider-Simmel Demonstration. It's from the 1940's, and the idea is that it's essentially a 2-dimensional cartoon in which four shapes— a circle, two triangles (one slightly larger than the other), and a box, interact. Over the course of about 90 seconds, the shapes move, touch, bang against each other, and appear to have some sort of story unfold between them.

Of course, it's all completely abstract, not unlike a Rorschach test. Its value is found when you show a person the animation and ask them to describe the story happening to the shapes. Some viewers would describe it as a love story, others might say it's a story of rivalries or bullying, while others still would come up with something wild or unexpected. This is due to the very human nature of inventing a story where none exists, or where there is not enough information for coherency, so we fill in the gaps, usually based on our own life experience. It's projection.

And this is why, from the outside looking in, DevOps can seem to be an unintelligible mess. There's no agreement about what DevOps actually is, so the ill-defined ball is taken and ran with in different directions by experts and gurus, all selling their own brand of DevOps which may or may not make any real-world, practical sense.

With thought leaders contradicting each other on the most basic issue— what this thing supposedly is— it's difficult for the mainstream to even understand what is being said. By extension, newcomers cannot or will not adopt DevOps, which makes the idea of a "DevOps Bubble" all the more credible.

The course we're running now isn't doing DevOps any favors. It's not only necessary, but important, that DevOps be defined simply and in such a way that anyone in the office could understand. If we want this thing to take off, let's leave the buzzwords at home and abandon the pretense. A "Thought Leader" title only holds meaning if, you know, people want to read your thoughts.

Topics: devops

UpGuard Customers