It’s 2017 and we’re still having this discussion? Alright then, here are some definitions for your consideration…
DevOps (and latterly Devops) is not a role. It’s not a team.
If you advertise for Devops engineer, or Head of Devops, then either you’re doing:
- keyword stuffing to reflect the language that your potential audience might use. This can be a recruiting hack done by SEO-aware people, begrudgingly
- it very wrong, for the reasons to follow
DevOps (a clipped compound of “software DEVelopment” and “information
technology OPerationS”) is a term used to refer to a set of practices that
emphasise the collaboration and communication of both software developers and
information technology (IT) professionals while automating the process of
software delivery and infrastructure changes. It aims at establishing a culture
and environment, where building, testing, and releasing software can happen
rapidly, frequently, and more reliably. – Wikipedia
Set of practices.
Collaboration and communication.
Not a job description.
Not a role.
Not a team.
My friend (and former colleague1) Gareth Rushgrove wrote some considered thoughts on this topic as part of the Government Service Design Manual. That has since evolved and no longer contains the section on Devops, but it remains available in the archive.
If your job advertisement says “devops engineer,” I guarantee you are
alienating the very people you want to hire. – Nick Stenning
An often-made comparison is to take agile. Agile is a way of working. You wouldn’t say you were going to hire an agile, so how can you possibly hire a Devops?
A rejoinder to that is to say that you can have agile engineers. I would say a strong “No!” to that position. Engineers familiar with agile ways of working? Sure.
If you are hiring someone to join your Devops team, I know you have at least 2 problems:
- You think Devops is a role/team
- You think a single team should be responsible for:
- evolving practices
- improving communication
- improving feedback loops
rather than those being concerns that should cut across the entire organisation2.
That screams siloed organisation to me. They’re fun, them3.
To do a bad thing, by ssh-ing onto a server and doing
sudo vi some-file to fix
the problem. Sometimes done during emergencies to restore normal operation to
some IT system.
I Devopsed the shit out of it
To break all the things at the same time, thanks to the joys of having automated large parts of your job. It’s now even easier to break everything, rather than just a single instance of a thing. We can write code which updates all our servers at the same time, rather than just updating them one at a time.
Oh crap, I Devopsed it
It could be argued that language evolves and the meaning has changed. Maybe Devops has been co-opted now, much like there used to be the distinction between cracking and hacking. These days, no-one really uses the former any more, and the latter has subsumed the meaning of the former.
Well, I care. I’ve seen too many organisations not appreciate the subtleties of looking at flow, feedback loops, and continuous improvement. That’s why this matters.
Thought you’d appreciate that, Mazz and Josh ;) ↩
Post to follow on that topic ↩