Why I hate DevOps

DevOps. The latest software development fad. Now you can be Agile, use Continuous Delivery, and believe in DevOps.

Continuous Delivery (CD), the act of small, frequent, releases was defined in detail by Jez Humble and Dave Farley in their book – Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. The approach makes a lot of sense and encourages a number of healthy behaviours in a team. For example, frequent releases more or less have to be small. Small releases are easier to understand, which in turn increases our chances of building good features, but also our chances of testing for the right risks. If you do run into problems during testing then it’s pretty easy to work out the change that caused them, reducing the time to debug and fix issues.

Unfortunately, along with all the good parts of CD we have a slight problem. The book focused on the areas which were considered to be the most broken, and unfortunately that led to the original CD description implying “Done” meant the code was shipped to production. As anyone who has ever worked on software will know, running code in production also requires a fair bit of work.

So, teams started adopting CD but no one was talking about how the Ops team fitted into the release cycle. Everything from knowing when production systems were in trouble, to reliable release systems was just assumed to be fully functional, and unnecessary for explanation.

To try to plug the gap DevOps rose up.

Now, just to make things even more confusing. Dave Farley later said that not talking about Ops was an omission and CD does include the entire development and release cycle, including running in production. So DevOps and CD have some overlap there.

DevOps does take a slightly different angle on the approach than CD. The emphasis for DevOps is on the collaboration rather than the process. Silos should be actively broken down to help developers understand systems well enough to be able to write good, robust and scalable code.

So far so good.

The problem is we now have teams saying they’re doing DevOps. By that they mean is they make small, frequent, releases to production AND the developers are working closely with the Ops team to get things out to production and to keep them running.

Sounds good. So what’s the problem?

Well, the problem is the name. We now have a term “DevOps” to describe the entire build, test, release approach. The problem is when you call something DevOps anyone who doesn’t identify themselves as a dev or as Ops automatically assumes they’re not part of the process.

Seriously, go and ask your designers what they think of DevOps. Or how about your testers. Or Product Managers. Or Customer Support.

And that’s a problem.

We’ve managed to take something that is completely dependant on collaboration, and trust, and name it in a way that excludes a significant number of people. All of the name suggestions that arise when you mention this are just ridiculous. DevTestOps? BusinessDevTestOps? DesignDevOps? Aside from just being stupid names these continue to exclude anyone who doesn’t have these words in their title.

So do I hate DevOps? Well no, not the practice. I think we should always be thinking about how things will actually work in production. We need an Ops team to help us do that so it makes total sense to have them involved in the process. Just take care with that name.

Is there a solution? Well, in my mind we’re still talking about collaboration above all else. Thinking about CD as “Delivery on demand” also makes more sense to me. We, the whole team, should be ready to deliver working software to the customer when they want it. By being aware of the confusion, and exclusion that some of these names create we can hopefully bring everyone into the project before it’s too late.

Advertisements

5 comments

  1. I am a tester and I very much am part of a DevOps team.

    I think part of the problem is how the term is expanded. If it is though of as a joining of DEVelopment team and OPerations teams then there is no reason for anybody who is currently part of one of these teams to feel excluded.

    I wouldn’t neccessarily put Product Managers and Customer Support teams in there as I feel their roles are somewhat different.

    1. That last sentence suggests you’ve missed an important point of the article Tom. Product Owners/Managers and Customer Support should definitely be involved in the delivery pipeline before it hits production.

  2. This is a deeper problem with terminology in my opinion. I view the “Dev” in “DevOps” as the base/super class Software Developer, describing any contributor to the process of developing software systems. A Software Developer may be a Test Engineer, Product Owner, Designer, Operations Engineer, aha! What do you now call the discipline usually referred to as Software Developer if that is the name we are giving the base class? That’s the cause of the naming confusion. A modern “Developer” is actually a Software Engineer or an Application Engineer maybe? In my day (1983-2000) my job title was Programmer then Analyst/Programmer then Senior Analyst/Programmer; the word Developer was never used. If it must be, as it is ubiquitously nowadays, then I’d go with Application Developer or App Dev for short.

    Having said all of that, names stick. Testers are often called QAs, yet testing is not QA (if the “A” is Assurance, as it most often is – others I’ve seen suggested are Assistance and Assessment, both of which sound more applicable to testing, especially the latter). They are two different functions, although one person could do both. Likewise you cannot automate testing, as testing includes exploration, which requires sapience. Machines cannot test for human usability. Checking/verifying is also a part of testing and this is what can be automated as it is repeatable; the expected outcome is known and does not change. Yet try using the term “automated checking” and see the looks you get. These terms (QA and Automated Testing) are so widespread and ingrained that they’ll probably never change, even though they’re used wrongly.

    Anyway, apologies for the lengthy comment. I got a bit carried away 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s