I recently spoke at DevOps Summit about what I think DevOps is lacking - as both a movement and a methodology - that it could learn from Extreme Programming, and this post is a condensed version of that talk.
But first, what do I mean by DevOps? One can’t construct an argument using something that’s badly defined. So a better question is “What can someone mean by DevOps?”
Know your enemy
Depending on who you talk to, DevOps can mean practically anything, from the concretely tool-focused attitude of “It’s all about developers using cloud providers and deploying their own apps”, to the process-orientated “It’s about communication between different teams”, to the wishy-washy nonsense of “It’s what you need it to be” (a meaningless sentence if there ever was one).
One thing I did notice was the staggering amount of detail that people were willing to talk about the “Practices” of DevOps, and that barely any time is given to talking about “Principles” or even “Values”. If anything, these things are in the opposite order of importance!
Values, Principles, Practices
When I talk about these three things, I mean them in the sense that they are defined in the Extreme Programming book. Values are … well … values, core ideas and needs that are placed at the centre of the XP methodology. It’s hard to over-stress how important this is - software developers are human beings too (honest!) and as such have needs. These values are small in number but lend themselves to whole sub-trees of Principles and Practices, and are written below.
- Communication
- Feedback
- Simplicity
- Respect
- Courage
I’ve ranked them in order in which I think that “DevOps” embodies and realises those values - it is primarily a methodology formed around methods of communication. Now, notice the two I highlighted at the bottom? Again, we have concepts that are equally as important as any of the others and yet they’re receiving next to no attention.
I would happily argue that it’s next to impossible to implement a good interpretation of DevOps without these two values. Without the Courage to change the way that the software development process at your place of work operates, and without the necessary mutual respect between co-operating teams, any potential “DevOps solution” will eventually crash and burn or fizzle out. Of course, these 5 values are not the be-all and end-all. Another mentioned in the XP book is that of Safety, often overlooked in software engineering. I was present at an intriguing talk by Joshua Kerievsky at JavaOne about this idea of Anzeneering, introducing and manifesting the same “Safety First” rigours required by manufacturing disciplines into software engineering, which has conceptually different hazards and dangers than actual physical engineering.
Wrapping Up
I don’t have anything against DevOps, not really, and this isn’t a post about the “purity” of DevOps, although there is a very applicable chapter on “Purity” in the original XP book.
My issue is that, and this is not at all limited to DevOps (I’m looking at you, Continuous Integration), it’s very easy to sell/peddle Practices and Processes and distract away from the reality that software development is made up of people who have needs and requirements - and as fun as the latest containerisation tools or provisioning systems are, they do not meet them on their own.
If you’re going to talk about DevOps, talk about the values and people-focused attributes necessary to build a good solution for your team, not about practices, tools, or processes.