After attending DevOpsDays Rockies I have to say it was an amazing event and both the organizers and sponsors have my thanks for putting together such a well run two day talk.
And it was also nice seeing two former coworkers again and listening to them as they participated in the ChatOps panel.
The Tools Don’t Matter
It was encouraging to see what I thought was an undercurrent of “it’s the people and not the tools” theme happening throughout most of the talks and open spaces.
Matt Stratton from Chef talked about “Managing Your Mental Stack” and Royce Haynes from Next Big Sound described his experience “Operating in a self-managed and self-organized company”. Both reflected this theme in a very direct way. Along with Dave Josephsen from Librato who gave a lighting talk called “Good to meet you; I’m an impostor here myself”. His message of we need less of us and more of you was very encouraging and I wish more people would follow that advice. And at least two different open spaces dealt with the people side of things… “How to escape the echo chamber” and “creating cohesion throughout all departments”.
Being technical people we tend to forget that most problems boil down to a communication breakdown or some other issue coming out of us people interacting with each other.
But what stood out to me the most after having attended the first and third DevOpsDays held in the US is that we are still struggling with the same questions we had five years ago.
As a professional community we’ve been focused on the tools side of things and haven’t addressed the people and management aspects of what we were asking about in 2010.
This is reflected by two common topics brought up by some attendees that I talked with or heard from during the open spaces. How to bring a Devops approach to their current workplace and issues related to communicating their needs and justifying them to management or other teams.
That we’re still asking how to get started makes me wonder as a community if we are doing enough to show others how to do so and if we actually even know what our own needs are ourselves.
Being people we still have issues with focusing on tasks at had and if you consider the amount of new technology and information being released throughout the year we shouldn’t be surprised that this is an issue.
The pace of using a new technology or technique to the point that you understand it and have an informed opinion of it will probably always be slower than the release of the next new thing. How can we expect ourselves to make good choices if we’re constantly moving from one thing to the next?
By focusing on the tools or the technology instead of the problem we’ve not advanced as far as we may think we have. It’s like we continue to just scratch the surface of the problem and then have another configuration management, deploy framework, or monitoring service introduced that we then consider and never really go beyond that. And now we have containers and related frameworks added to that menagerie of things we’ve been focused on.
I mean we’re still talking about the benefits of infrastructure as code, monitoring and testing like they are new things.
Consider the following six titles of talks given at various DevopsDays. Can you pick which one is from about five years ago or more?
Infrastructure as code
DevOps requires visibility
5 Common Barriers when Introducing Devops
Making the business case
Continuous Integration, Pipelines and Deployment
Changing culture to enable DevOps
To add a bit of a gap to the answer to that question watch this short five minute intro video that was show at the first DevOpsDays in Mountain View from 2010.
Five of those titles are talks from DevOpsDays in 2010 and 2011. The odd man out is the “5 Common Barriers when Introducing Devops” talk that was given during DevOpsDays Silicon Valley 2014. Yet any of these could have easily been a talk given more recently.
Our profession is more than just a slide deck and this is not to diminish the information shared by any presenter. It is to say that we need to take these litle sparks of ideas and information and build upon them. Use them as a queue to dig deeper into these problems that we keep talking about. Otherwise in my opinion it feels more like we’re treading water and not making the advancements we could be making.