Sifting through some material the other day I stumbled across a view about DevOps that was put forth very passionately and articulately. However, it was at odds with how I see things and made me think about the subject one more time.
The central theme of this article that I read, as I understood it, was that DevOps equates to having superhuman developers doing everything single-handedly, from software development to QA, Release Management, Deployment, etc. and that that’s the only way it can be.
I disagree. The essence of DevOps, where the role of the developer is concerned, is having more control over the lifecycle of the software being written. Also central to DevOps is collaboration between the development and all other supporting functions. But today, I’ll speak only about the former.
So what do I mean by more control? Here’s an anecdote—and it’s not made-up—that might help explain what I mean.
Some time ago, we needed to get this software fix into production urgently. During a heated discussion on the topic, one of my past colleagues, who also happens to be dear friend, was asking very passionately (I have paraphrased his questions here): “Why should I (a developer) need to prepare and pass release notes to individuals who, more often than not, don’t fully understand the implications of the software change or the release tasks? Not only that, but some other gate-keeping group will then decide whether to release the fix or not. And, after having spent all this time and effort going through this process, guess whom the gate-keepers are going to come back to and ask if it is alright to put the fix in—me!“
Although there are well established and traditional sets of reasons behind such processes, I will stick to the central theme of this post here and probably discuss their merits and demerits at another time. Coming back to the question posed by my friend, it is after all the developer who has the best insight into the implications of software changes being made and released into any environment. Then why should we not trust the developer to be more in control of change that he or she has coded and needs to be released? We should. We should trust the professionalism of our software engineers and empower them to take more accountability for the consequences of making changes to software.
It does not mean that the developer does everything. Far from it. It is an enabler for software engineers to get better control over the progression of their code and become more empowered to take the right decisions quickly.
For organisations, this creates a very engaged community of software engineers and other supporting IT functions. It also saves time, and therefore money, by removing some of the hand-offs and streamlining the decision-making and implementation processes. It does not matter whether the organisation is a small start-up or a large corporate enterprise. The drivers, constraints and resulting DevOps implementation models for different types and sizes of companies will vary, but the principles, in my opinion, apply uniformly.
What I have talked about today is just one specific aspect of DevOps, and purposely so, because of the opinion that I had recently read about it. This is just one of the things that DevOps is all about. I will try to expand on other scenarios of collaboration, communication, automation, engineering practices, culture, etc. and the challenges associated with some of them in due course.
What do you think?