Slashdot Mirror
How 'DevOps' Is Killing the Developer
An anonymous reader writes "Python guru Jeff Knupp writes about his frustration with the so-called 'DevOps' movement, an effort to blend development jobs with operations positions. It's an artifact of startup culture, and while it might make sense when you only have a few employees and a focus on simply getting it running rather than getting it running right, Knupp feels it has no place in bigger, more established companies. He says, 'Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once. If such people even existed, "full-stack" developers still wouldn't be used as they should. Rather than temporarily taking on a single role for a short period of time, then transitioning into the next role, they are meant to be performing all the roles, all the time. And here's what really sucks: most good developers can almost pull this off.' Knupp adds, 'The effect of all of this is to destroy the role of "developer" and replace it with a sort of "technology utility-player". Every developer I know got into programming because they actually enjoyed doing it (at one point). You do a disservice to everyone involved when you force your brightest people to take on additional roles.'"
100% inclined to agree. DevOps is not really about your best and brightest pure programmers, but taking all of your jack-of-all-trades guys who specialize in "making shit work" and allowing them to keep things working.
This sysadmin/scripter/system architect/DBA role exists in virtually every company that has a core business other than IT or software development. Even in a very large multinational, there's more utility in having one "Mr Wizard" in each business unit than there is in having a room full of software developers somewhere far away from the rest of the business.
It really is a support role and it's more an outgrowth of system administration than it is saddling your brightest software guy with managing the mail server. Of course, it's possible to get stuck in that role because there's nowhere to go from there, but it's a niche that suits some people. If it doesn't suit you, then move.
It's also a distinct role from the "do everything guy" at a startup, because at a startup everyone is multitasking and as the startup expands, new people are hired to take on some of these roles. DevOps is a role in itself.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
There's definitely truth to what he's saying but it cuts the other direction as well. Having your lead guru developer swapping disk drives on a machine isn't the best use of his time. However, I've also seen environments where the developers can't/won't/aren't allow to do the system admin tasks and wind up waiting around or being frustrated when their development systems have a problem. Likewise, with QA - I've seen developers that will just toss any old crap over the wall and expect QA to catch all of their bugs. And, developing tests is often software engineering, often complex software engineering that needs an experienced developer to establish at least the outline of how everything works.
Personally, I expect any developers I'm working with to have at least basic sys admin abilities and know how to setup/fix any other part of the stack they might touch. Those skills should be used when working with the dev systems and in establishing the base line for production. I would then expect that someone who is more specialized in those other roles to actually setup and run production and also be available when the developers get in over their heads on system admin, hardware troubleshooting, etc. In the same way I would expect a systems admin to at least be able to write a script to automate something and not go running to the developers for everything.
For test development, I always like to set groups against each other and develop the test suite for each other's code. Most people are a lot more comfortable and eager to break someone else's code than they are their own.
I had a job where I did everything once, wrote a full-blown ERP system for hundreds of users, all by myself. Everything. Though I was salaried, sometimes I worked whole weekends, or to 2 in the morning - not because I had to, but because I wanted to. No politics, no being just a cog in a machine, no project management, no BS. Just me and code, giving people what they needed and making their jobs easier. It was my dream job, my first and best job, and I've never had anything like it since.
This DevOps movement the author speaks of... I've never seen it, not in all the years I've looked to find it again. He may complain that it's bad, bad for the industry, but I would take it in a heartbeat.
Is that what I was, a DevOp? I miss it so much I can taste it.
The point of devops is not to take jobs away from developers. The point of devops is to provide an interface between system administration and development. Development and system administration have always been at odds with each other - system administrators not really understanding or caring how the application works, and developers treating the systems as an infinite resource pool with no real rules or resources past "does my code run?"
The sole purpose of devops is to ensure efficient operation of the infrastructure in a way that allows for repeatable deployments and controlled versioning, and that also includes system software such as operating systems (sysadmins benefit too because they no longer have to do one off deployments of OSes).
This criticism strikes me as woefully underinformed as to what devops actually does, and I'm wondering if the author of this is a developer who is upset because devops is forcing them to actually use the software lifecycle properly rather than just doing cowboy deployments and hoping they work.
For linux tips: http://www.linuxtipsblog.com
You forget about the ops part of devops. A lot of ops people need to be made to care about what is running on the boxes they are supporting. By knowing more about what is going on it can help then priortize the work which they are most experienced at, along with helping the "brightest pure programmers" understand why the cool solution they developed is a POS in production.
DevOps is all about creating dangerous conflicts of interrest.
No.
And I'd even go so far to say that we need MORE conflicts of interests.
A software company is full of conflicts if interrests. You have the sharholders who want money, sales who care about release dates, customers who request a feature, devs who know that that feature will have unpleaseant side-effects that the same users would not accept and so on.
"Resolve" those "conflicts" by completly seperating them into different roles, and you have a company where departments will fight each other to the bone and management will be busy with conflict resolution instead of actual work.
You need to have people inbetween those branches who know how to make them work together.
bickerdyke
No, the point of "devops" is getting your employees to do two jobs.