Monday 21 April 2014

Is 'DevOps' Killing the Developer?

This post is inspired by a blog post by Jeff Knupp entitled "How 'DevOps' is Killing the Developer'. If you haven't read it, go and do so. It's a very good read and can be found here.

For those of you that don't want to spend the time reading it, as a quick summary, Knupp argues that the 'DevOps' movement is changing what the world considers a "developer". Before, a developer would the guy that pumps out lines of code. Nowadays, due to the start-up mentality, developers are now expected to not only produce code but also to act as a system tester; a system admin; a DBA and a systems analyst, all rolled in to one. Knupp argues that this wrong. That it stops developers doing what they enjoy and what ultimately, they're good at which is producing code.

I think Knupp is wrong, to a degree, and this is why...


To take a phrase Knup uses, a 'full stack' developer is not only wanted by companies. They're needed and saying a developer should just code will affect the quality of the system they're building. I don't deny that most developers should be developers in the traditional sense but depending on the size of your team, you need at least a few that have the skills and the knowledge to be a 'full stack' developer, or in other words, a DevOps guy.

Why?

'Full stack' developers have two major plus points:

1.  They can predict problems that traditional developers can not.
As they understand the entire process, they can anticipate problems from external systems before they actually happen. This will lead to a system that is more stable. For example, they have a good understanding of the database. With this they can look at a design of a system and anticipate where bottlenecks at the database level will exist and then they have the ability to change the design accordingly.

2.  They can take ownership of any bug.
This is a huge benefit. They have the ability to find the cause of bugs that other teams don't. Bugs that require knowledge of how everything works together.
Here's a typical scenario. A customer logs a problem with their live system. The customer support team refer it to the DBA's because the problem looks database related. The DBA's look at it, can't find any immediate problem with the database and forward the problem to the developers. The developers look at it and find it works fine in the customers development environment. As the development environment and the live environment, from a code standpoint, are exactly the same, they forward it back to the DBA's. This process repeats. No single technical person can take ownership for that bug because neither believe their area is the cause. The bug takes a significant period of time to resolve at the expense of the customers happiness.
Enter the 'full stack' developer... the bug gets put on their desk. They take ownership of that bug, there's no need to bounce it from department to department, they investigate the bug and find the problem to actually be some proxy server doing something it shouldn't. For the developers this is hard to find as the tools they use to debug problems don't enable them to find such a problem. The DBAs can't find it because it turned out the problem had nothing to do with the database anyway. The network guys could have found it, but why ask them? The problem wasn't originally attributed to a proxy server. The 'full stack' developer knows all of these systems well enough to find these odd, but sometimes critical, problems and when your customers happiness is directly related to how quick that issue gets resolved, this knowledge can prove to be invaluable.

One point that Knupp makes which I do agree with is that these DevOps guys find themselves doing things other than coding. But is this a bad thing?

Generally speaking, you want your staff doing what they do best and in this case, 'full stack' developers are best at coding. You wouldn't hire a developer and put them on reception for example. However, let's analyse the nature of these DevOps guys. These guys are inquisitive, they want to know more. So when faced with a problem they don't just pass it on, they take the opportunity to learn a little more and find the solution themselves. They do this because they find the field of I.T./Computer Science/Development/whatever you want to call it, interesting and want to learn more. Over time, they've investigated enough problems, found enough solutions that they've learnt enough to be considered a 'full stack' developer. Should people like this be confined to "just coding"? Would that give them the ultimate job satisfaction? Is that enough to keep these developers at your company? After all, that's what you want to do... any developer that wants to carry on learning is one you'll want to keep.

In conclusion then, is DevOps killing the developer? I'd argue no. Being a DevOps guy takes a certain attitude and there are plenty of developers out there that are more than willing to just write code. And that's fine. That's better then fine, it's fantastic! But should we be shunning DevOps then? Again, I'd argue no. There's a place for them in any software house, an important place at that. The key to getting the best out of your DevOps guys is the real problem here. How to balance coding time to the other duties they end up performing. It's a fine line but one that if you do get right, has some great rewards.