Two terms I love. Two terms that are often used interchangeably. Two terms that are in danger of becoming buzzwords… like agile. I don’t want that to happen.

In order to avoid these terms going the way of agile, we need to understand exactly what they mean. We also need to understand what makes them different and unique from each other. Can you say, hand on heart, that you can easily articulate the difference? If you can, would you assert that the rest of the DevOps and continuous delivery movements would universally agree with you?

In my view there is not a strong enough and universally agreed distinction between the two. And if people can’t agree on what makes these two movements unique from each other, how can anyone claim that they can define each individually? And if no-one can categorically define them, perhaps they are in grave danger of becoming marketing or recruitment buzzwords.

Perhaps they already are? I hope not.

This post is my attempt to articulate my thoughts on the topic. I encourage you to share your views too.

Is one a sub-category of the other?

This post was inspired last month when I heard about a very public debate between Dave Farley, who co-wrote Continuous Delivery, and Steve Thair, who co-founded DevOps Guys. Both these men are people I have a huge amount of respect for but the fact that these two well respected members of the community could see things so differently worries me. If they can’t agree – what chance do the rest of us have?

Both had created a slide/flyer/blog post etc that had described one as the sub-category of the other.

For Dave continuous delivery is about applying the scientific method to software delivery. He believes that through scientific experimentation, fair (repeatable) tests and proper analysis of data to underpin learning we can deliver better quality software that better meets the needs of our users. As a result, his book reads more like a scientific textbook than most of the stuff you read about DevOps. His talks are often very structured and he likes to use diagrams and charts in his presentations.

The overarching goal is a scientific approach to delivering software, and the mechanisms to do that, including DevOps stuff like repeatable deployments, collaborative working, auditable pipelines etc, are all just the building blocks toward that goal.

Steve views things differently. The DevOps movement starts with collaboration and automation. The benefits of deploying frequently and iteration are simply a given. These benefits aren’t discussed in terms of scientific study, but they are thought of as lean manufacturing principles with similar consequences. The foundation of DevOps is not an effort to be more scientific, it is an acknowledgement that the IT world sucks at inter-team collaboration and that as a result we are inefficient at delivering software and terrible at managing the quality of our code. DevOps applies manufacturing principles to the delivery of code as a way to resolve these issues.

So DevOps is not a journey towards scientific purity, it is a journey toward sound engineering and delivery principles, and it starts with breaking down silos and mapping out the entire delivery pipeline so that it can be optimised. Continuous delivery is simply the process, but DevOps is a bigger cultural shift.

Personally, I do not see how either continuous delivery or DevOps can be defined as a sub-category of the other. They come from different places and are backed by different ideas and methodologies. To define one purely as a small part of the other is hard for me since I don’t feel that the ideas at the foundation of either are inclusive of the ideas that define the other.

Are they the same thing?

But hang on a second, what are the instructions that continuous delivery and DevOps provide for us?

DevOps promotes the idea of the three ways: systems thinking, amplifying feedback loops and developing a culture of continual experimentation and learning. It’s about CALMS: Culture, Automation, Lean, Metrics, Sharing. It’s about improving the visibility, testability and optimisation of making changes.

Continuous delivery promotes the ideas of continuous integration, which itself is a practice based on the management and testing of changes. It then promotes that these changes should be deployed in a consistent, reliable and automated fashion. It promotes frequent iterations, experimentation and fast feedback loops.

Aren’t they essentially working off the same hymn-sheet?

Let’s compare the Bibles of each movement:

Dave and Jez’s followers often refer to their book, Continuous Delivery, as ‘the Bible’. In the same way that the Holy Bible is often used as a reference book by Christians who are considering various moral or spiritual issues, Continuous Delivery is intended as a reference book that can be used to instruct on how to solve certain software delivery problems (including DLM :-P). It is not designed to be read from end to end.

Arguably the Bible for DevOps is The Phoenix Project. A fictional parody of an IT organisation. It’s a comedy! A satire of software delivery done wrong that does a very good job of paraphrasing many of the seminal texts of our industry (including Continuous Delivery) and explaining how they fit together in the context of a ‘real’ team with ‘real’ problems made up of ‘real’ people – emotions and all. It’s hardly presented as science. It isn’t academic, but it is pragmatic, genuine and very well researched.

These IT books couldn’t be more different.

The two methodologies may come to similar conclusions and may make similar recommendations – but they are not the same. The ideas and principles at the foundation of each are wildly different. DevOps starts with manufacturing principles and a pragmatic understanding of human and team behaviour. Continuous delivery starts with academic and scientific principles.

Is one superior?

Everyone will have their own opinion on this but I strongly believe the answer is no.

Most atheists and most religions alike promote the ideas that stealing is wrong and kindness is good. Most law systems promote the same ideas whether or not the laws were inspired by religious or secular values. Most of us, regardless of culture, religion, class, education, childhood experiences, nationality or [insert other variable] come to broadly similar conclusions about the simpler moral questions – but we arrive at them in different ways. Would you be comfortable to state that one morality system is objectively and universally proved to be superior to the others?

For me the fact that both DevOps and continuous delivery end up promoting very similar practices is not a cause to debate which is the better argument for trying to adopt these practices. Instead each supports the other. If you would like to adopt the sorts of practices that continuous delivery and DevOps promote you now have two different but well respected sets of materials that you can reference to explain the benefits to your colleagues. You can pick whichever set of ideas you think your colleagues will appreciate more. That’s a wonderful thing.

Just like that there is almost always more than one way to prove a mathematical equation, and that there are many different arguments for why murdering people is wrong, I believe that DevOps and continuous delivery are two different arguments to support the idea that certain practices are likely to improve your ability to deliver software.

Rather than debating which is better, perhaps we should view it that each supports the conclusions of the other in their own way. And that is a good thing, we’d all be on shaky ground if they ended up in wildly different places!

What do you think?

The purpose of this post is not to be the person who defines either continuous delivery or DevOps. Neither am I trying to define the difference between the two. These definitions should come from the community, rather than a single person. I’m sharing my thoughts to prompt you to think about the differences between the two and what makes each unique. Is there a glaring difference which I have missed? Have I got it all wrong? What do you think?

If you have some views on the subject I think it would be tremendously valuable if you were to share them as a comment below, on your own blogs or on whatever other platform you wish to use. I believe that as a community we should make an effort to explore this topic as it will help us to understand what makes each of these movements unique.

And this, I hope, will help us to call out marketeers or recruiters when they use the phrases badly.