Jeff Knupp wrote about “How DevOps is killing the developer“. I wanted to respond to this blog post, because you hear this view more often. But I think it stems from a misunderstanding about how DevOps is implemented in different size teams. Thats why I wanted to write about how DevOps should be implemented differently in small and big teams. But lets say first and foremost, DevOps will never kill the developer. How much Dev and Ops responsibilities are performed by the same person depends on the size and maturity of the company, but developers will always exist.
The goal of a company should be to get software into production in an efficient manner. This is where DevOps can help. The way to do this is by optimizing the development and operations processes by seeing them as one process instead of two different processes. Achieving this goal can be done in different ways and in my opinion this results in different solutions for different size teams.
Small teams
The DevOps terms stems from startups. DevOps practices are relatively easily incorporated in startups because of their flexible nature, their relatively small teams and the DevOps practices probably aren’t far from the way they were already working. In smaller teams Dev and Ops responsibilities are already assigned to the same person which gives him/her the opportunity to optimize the full process.
Most of the time smaller teams (or single programmers) were already doing DevOps without knowing the term. Introducing DevOps might improve on that process and gives them a job title which more resembles their day-to-day work. In companies like this there might not be a “developer” as such anymore. But this will hopefully change when the company grows, and teams get bigger.
Bigger teams
When DevOps is practiced in bigger teams, DevOps works differently. Instead of sharing different parts of the job, DevOps is much more about communicating what you are doing and understanding what the other guy/girl is doing. And if you know what everybody is doing, it becomes possible to optimize the full process (the end goal).
When I look at developers and operators skills, I think of a T shape. The horizontal line stands for their broad knowledge on multiple subjects. The vertical line stands for specialization in their main specialism. For everyone the T will have a different shape. The horizontal and vertical lines will be different lengths for different people. Some people will specialize is a subject, but might not have a very broad view about other subjects (specialists). Some people have a broad view (know a little about everything), but it you go a little deeper into a subject, they are lost (the high level view). If someone focuses more on the vertical or horizontal line depends on your character. A healthy team should have a mix of different people.
Implementing DevOps means expending the horizontal line of the T shape for some people. It means that developers need to know more about operations. And that operators need to know more about development. But it doesn’t mean that the developer will do the operators work or the other way around. The members of the team will still have their own specialism (the vertical line) and work inside that specialism. We just try to give them a broader view. For some people this goes against character (they like to focus on their main skill) and this can cause friction and resistance.
How do we give people this broader view? Most effective is improving communication between people. An effective way is combining the operations team and the development team. The close proximity results in closer/better communication (if we do it right, but lets assume we did) and it gives the team the freedom to make the necessary changes, because all the stakeholders are represented in the team. The team becomes responsible for the full process and can optimize it. Note that I didn’t say here that one person is responsible. The team with stakeholders from the different disciplines must agree on the optimized process, but all the specialists will focus on implementing their part of the puzzle.
Although the way of implementing DevOps might be different, the result should be the same. The result should be an more efficient way of releasing software. This doesn’t mean that the developer “will be killed”, but DevOps makes sure they do a better job, be more efficient and have a clearer understanding of their environment. DevOps makes a developer more professional.