Cargo Cult DevOps

DevOps is a very successful meme in our industry. Most organizations these days seem to be saying that they aspire to it, though they don’t necessarily know what it is.

I confess that I have a slight problem with DevOps. Don’t get me wrong, DevOps and Continuous Delivery share some fundamental values. I see the people that promote DevOps as allies in the cause of making software development better. We are on the same team.

At its most simple level I don’t like the name ‘DevOps.’ It implies that fixing that one problem, the traditional barrier between Dev and Ops, is enough to achieve software nirvana. Fixing the relationship between Dev and Ops is not a silver bullet, and the originators know, and say, that. There are other significant barriers: the gap between the business and technical teams, testers and developers…the list goes on. More than barriers between teams, the approach to requirements capture and specification, testing, design, development, configuration management, deployment, etc. all have implications on our ability to release valuable features as quickly as possible into the hands of our users. The problem as I see it is that a naive view of the DevOps name makes it sound simpler than it really is.

It is also too vague: while the focus on the importance of DevOps culture is important as a liberator of innovation, DevOps rarely says enough about the goal of delivering valuable software into the hands of our users cheaply, efficiently and reliably to help us figure out what to do next to make it work.

Check out the Periodic Table of DevOps Tools v.3!

The problem is not really the fault of the originators of the DevOps movement. As with most ideas, people will often take a superficial view and so miss the important details.

During the second world war U.S. armed forces created airstrips and small bases on Pacific islands. The Americans brought all sorts of cool things, food, medicines, technology, even huge metal machines that descended from the skies and brought the supplies. Years later, after the bases had been deserted by the Americans, other people visited the islands to find some with airstrips hacked out of the jungle, bamboo control towers manned by people with radios and head-sets made from wood, and bamboo sculptures of aeroplanes. They had discovered the ‘Cargo cults.’

The islanders had recognized that there was some connection between people sitting in control towers and the arrival of cargo beyond their wildest dreams. They wanted some of that, so they tried to recreate, what they believed to be, the essentials of the system to recall the metal machines from the skies.

DevOps sounds simple. “It’s all about combining Dev and Ops – right?”, “I know, let’s create a DevOps team, recruit some DevOps engineers”, “Let’s buy some DevOps products and fix our problems”. Like the islanders and the cargo, every organization wants the goodies; To deliver high quality high value software to their customers, as the best Continuous Delivery organizations do. They want the business to be able to experiment with ideas and find what works best. What’s not to like?

The problem is that this is hard to accomplish. It requires a change in culture across the whole organization. There is no sticking-plaster solution. Adding a DevOps team is often just creating yet another silo. Recruiting DevOps specialists doesn’t necessarily change your Dev and Ops teams. The culture change that you really want is to make developers responsible for their code in production and operations people responsible for the design of code that can be maintained in production – highly collaborative teamwork. This may mean that developers and operations people will need to learn new skills but this is not a different discipline, merely the same old disciplines done well. You may buy some tools to help with DevOps, and these may be good tools. All of these things have their place, but unless these actions are part of a broader, more cohesive approach your radios will still be made of wood and you will not get the hoped-for cargo.

I think that DevOps and Continuous Delivery are trying to say similar things. As you might expect, as someone closely connected with Continuous Delivery, I like its way of talking about this stuff better. I think that CD provides more concrete descriptions and tools for doing the right things. Nevertheless, the founding principles are shared, and as I said at the outset, we are on the same team. For software development to work it must be based on established feedback-cycles, high-bandwidth communications, really effective team-work. It is based on iterative approaches to all aspects of development, product vision, design, development testing and release. It is based on empirical evidence rather than guesswork. It is a more scientific approach to software development overall.

This means analyzing what you do, on a regular basis, and making it better. It means dropping practices, technologies, sometimes even people, that don’t work and replacing them with ones that do. There can be no sacred cows, no “we always do it that way”, no “we must do that because X said so”. This is no place for cargo-cultism. Completely the reverse: we must be rational, empirical, experimental. We should approach things with a skeptical mind, try things out, some of which will not work. We must break down any barriers to efficient communication and efficient team working that impede our ability to deliver high-quality software on a frequent basis to our users, including that barrier between Dev and Ops.

For me Continuous Delivery is more explicit in identifying the mechanisms that facilitate this way of working. The focus on reducing cycle-time, automation and the conscious establishment of feedback loops are crucial to making this stuff work.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

                                   The First Principle of the Agile Manifesto.

Despite my CD bias, I am sure that most DevOps experts would agree with these goals. This article is not about “My process is better than yours” it is about “What should your organization do to get to the high ground of effective process”. I suggest that as a first step look at your cycle-time, from “idea” to “valuable software in the hands of your users”. If the barrier between Dev and Ops is a significant one in your organization, this analysis will highlight it and give you the understanding to begin to change things. If other barriers are more pressing they will show up too.

Continuous Delivery and DevOps are holistic approaches to software development. The techniques that we describe often interact in subtle ways. It takes a long time for teams to get good at these things and it will affect the way in which you organize your company, not just your development or operations functions.

The closest we can get to the electronics in the radios is the idea of cycle-time. Work to reduce that, do whatever it takes. Break down barriers, increase automation, increase collaboration  and iterate.