A DevOps one-liner?

, ,
A DevOps one liner

tl;dir You can try but you risk people either misinterpreting or making assumptions so you end up having to explain what you mean anyway.

I was recently asked if I could explain what DevOps was to someone new to the software industry and in attempting to do so I came up with a one-liner


A principled approach to ship working software reliably, repeatedly and consistently to enable fast feedback that the system is providing value to the end users.


But the more I thought about it the more I realised how loaded this fairly simple one line actually was and needed to break down each part to make sure that I didn’t mislead the person inquiring about what it was.

Principled approach

The idea behind this is to mitigate the cargo cult that has a tendency to happen with agile initiatives.  This is where teams blindly follow the ‘rules’ without ever understanding the why or given the time to understand.  By making your DevOps initiative a principled approach you not only force the team to state what their principles are but in trying to articulate them they have to actually understand them.

By making them principles you can avoid dictating to teams how they should work and what tools they should use. This should be a team decision with justification stemming back to the principles. This then gives the team a mechanism for assessing what they actually need rather than what the sales team of the tool thinks they need. Also because they are principles they can at a future date be easily revised once the team has learnt what is and isn’t working for them.

So what should your principles be? A good place to start would be the DevOps Handbook or go back to Agile Manifesto and adapt them to your context.

Ship working software

This must be to the live environment not staging, development or some sort of testing environment, but where real users actually interact with the system.

It doesn’t have to be every single users but at least a subset. I’d also go to say that beta groups don’t count here as they tend to be self selecting and may not be as representative of your real users.

The shipping part must also be done by the team building the system not some sort of operations team. They must be able to do this themselves otherwise they’ll never feel the pressure of their actions affecting end users. There is nothing like knowing your work has direct consequences on users to make sure you’ve done everything to make sure your changes actually work.

Of course it must functionally work which leads onto

Reliably, repeatedly and consistently

Pushing to the live environment must be reliable meaning that it works every time and doesn’t need specialist knowledge to be able to deploy. Ideally everyone in the team should be able to push from Developers and Testers to BAs and the Product Owner. At a bare minimum everyone of the Developers and Testers can push to live.

It must be repeatable so that you can deploy either once a week to once a minute (that might be a little on the extreme side but being able to allows you to push out fixes a lot quicker). It also helps de-risk releases and turns them into non-events, it’s just something you do like pushing to source control.

For pushing to live to be successful at being reliable and repeatable it must also be consistent. It’s the same process for everyone, there is only one (official) mechanism (preferably one button push) and the outcome is always the same meaning no nasty surprises like taking down the whole system. If it does break then backing out the change is as simple as one button or because you can push to live so easily a fix can be turned around quickly.

Fast feedback

To ship working software reliably, repeatably, and consistently you are going to need some good feedback systems.

Building in testability into your product from the start provides early feedback that functionally the feature works. Continuous integration lets you know that it integrates with the rest of the system early and if you need to course correct. Having your Testers involved from the very beginning of the the feature helps them to inform the whole team how the feature is likely works for the end users.

Coming up with results for which the feature will be measured against at the idea stages means the telemetry needed is built in from the start and helps the team to understand if it is heading in the direction the organisation wants. Not only that it helps the team to see if any subsequent alterations or other features from other teams have any effects on your work (negative or positive).

Providing value to the end users

This is possibly the most important aspect of any system being built. If it’s not meeting some sort of end user need that they find valuable then it doesn’t matter how well you do the other parts of your system, it isn’t going to last long and nor are you as a team or organisation. Ideally almost everything you’re doing is in direct (a new feature) or indirect (CI pipeline to deploy faster) benefit for the users.

If you can justify the effort that either improves the system for the end users or makes it easier for you to deploy faster or understand what is and isn’t working then it’s worth doing.

One of the best ways to start focusing on the end users is to know who they are.

This sounds simple to focus on the end user and if you ask any team if they do I’m certain almost all will say yes. But if you look at the work the teams is outputting it’s sometimes very difficult to see how it benefits the end users or if they were even considered again after the initial discussion on the new feature/update. A lot of teams haven’t even had contact with their end users or seen them actually user their systems.

Focusing on the end users isn’t simple thinking about them every now and again but actually finding out who they are, why they use the systems and how they actually use it. Remember a lot of people say one thing but actually do another so make sure you have multiple ways to understand how your users interact with your systems.

From there you can start seeing how you’re providing value to them even if they can’t articulate it to you. This way you’ll always stay a head of the competition and if any new entrants are likely to start stealing users from you.


You can come up with a one liner but you risk simplifying something too much that people think it’s easier than it is or they make assumptions which leads to a whole host of other problems. Such as people thinking they are talking about the same thing but both have a different understanding of it e.g. a quick ( and very unscientific) Twitter poll to gauge people’s thinking of DevOps varies quite a bit

It’s one of the reasons why I say we should just stop calling it DevOps to get people to explain what they mean rather than everyone assume they are all talking about the same thing.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.