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.'"

Comments

whine

[phantomfive]

Python guru Jeff Knupp should go find a job where he can program, and not worry about ops. Simple solution.

Re:whine

[Anonymous Coward]

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.

Re:whine

[Ice Station Zebra]

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.

Re:whine

[mlts]

I have seen some companies have their developers given autonomy, with their own DevOps, mainly because it allows for what is needed to get granted. New subnet for lab testing? It is a lot easier to get a DevOp guy to configure the VLAN for it than to submit a ticket to a different organization that isn't connected at all, nor knows what needs done.

Of all the organizations in a company, dev needs the loosest reins (while still keeping separation so that the loosened policies don't allow for a security breach to compromise other departments.) The other department that needs autonomy is QA, because $DEITY knows what needs to be tested against.

So, having an autonomous DevOps means that the dedicated programmers have people that know what they want/need, and have the ability to get that.

In my experience, this does seem to work and work well in SMBs that are not just hiring H-1Bs or offshoring their entire dev department in toto. Larger companies, depending on corporate culture, not so much. Dev and QA should be autonomous. They have to be because that is where things get invented and bugs get squashed.

Re:whine

[Penguinisto]

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, right here. I inherited the DevOps job title, even though it is exactly what I've been doing for years now. I can go in, find a problem, test a simple fix, turn QA loose on that fix, and even with change management, I can have it implemented far faster than the devs, who might fit it into their next sprint if you're lucky. They naturally get informed and fit a more elegant solution in for the next release (and sometimes they leave my fix checked-in just as it is).

Meanwhile, while yeah in a start-up company the developer(s) had to play sysadmin too, all-too-often they don't really know much beyond the basics, and so you really don't want one, say, tweaking HugePages in sysctl.conf, or planning SAN or VM Farm expansion for the next web project, or lots of other things. Similarly, I refuse to dig any deeper in code beyond the simply Python tweak or the obvious fix/workaround, since I only know enough to be dangerous when it comes to all of the dependency chains, not to mention all of the subtle gotchas in all of the codebases I work with (why? Because while a given developer may only need to dork around with (or even just only a part of) one codebase, I have to wrangle multiple projects - time demands that I prioritize what I know about them all).

It bears a lot of responsibility - you have to know what the frig you're doing, because downtime==money, and stakeholders will have none of it. On the flip-side, you're given a lot of leeway when it comes to what you're allowed to do in order to keep the uptime flowing. For instance, I get priority, where I can call up a network admin, security admin, or whoever I need to put through a change as soon as safely possible. I can order-up (within reason) whatever CapEx I need to build up for the next release, project, or what-have-you. Of course, you have to justify what you do, and if you do something stupid it's your nuts on the chopping block, but overall it balances out.

IMHO (and little else), I've seen a lot of sysadmins able to step up to the DevOps plate, but very few developers that would be willing, let alone capable (most that I know prefer to write code, and not get their hands dirty with the business of playing server-monkey or wire-monkey.)

Re:whine

[Anonymous Coward]

No, the point of "devops" is getting your employees to do two jobs.

Re:whine

[RabidReindeer]

21st Century Business Logic:

1. Multi-task. Never devote your entire attention to one task when you could be juggling 7.

2. Run Lean. Why hire a dedicated expert developer, a dedicated sysadmin, a dedicated DBA and a dedicated network engineer? Make one person do all those things (see #1, above).

3. Run 100% and demand 110. Who needs expansion room for when things inevitably go pear-shaped? Which Murphy guarantees even when you don't tempt him with #1 and #2.

4. Run cheap. Demand maximum expertise from the lowest bidder. There's always someone in a third-world country who'd be GLAD to do items #1, #2 and #3 for pennies a day!

5. Use easily measured things to determine employee effectiveness. Lines of Code, Time on Phone, stuff that's easily objectively measured, unlike less tangible things like customer satisfaction (what, you think we bother to ANSWER those silly surveys?), externals (like poisoning 6 downwind countries) or time to do the job right the first time. Use these as weapons to demand more of #1, #2, #3 and #4.

6. Subscribe to overpriced buzzword-laden management fads to assist in accomplishing all of the above.

This role exists in any non-software business.

[fractoid]

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.

Nothing new here

[nitehawk214]

Seen this many many times before. Cheap companies that have lots of developers and are too cheap to hire experienced admins... or an IT shop that thinks they can have the IT guys program instead of hiring proper developers. "hey, you work with computers, you guys can all do the same stuff, right?" Wrong.

While I have known developers that can sysadmin, and admins that can program... they are the exception not the rule. Quality suffers when you force people into jobs they are not qualified for. Companies know this, and they simply don't care as long as the managers think they are saving money.

Just because you can doesn't mean you should

[putaro]

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.

Re:Author is dumb

[fractoid]

I'm a senior developer at a 21 year old startup that does C# thick clients over Microsoft SQL back ends.

At a what? Are you at a 21-year-old company or are you at a startup?

Or are you at a 21-year-old company that pretends to be a startup when they say things like "hey guys we're a startup so can you work this weekend?"

Re:Oh please...

[dnavid]

The problem that others are having with DevOps is that they seem to be defining it differently than you are. What you wrote makes sense but the scenarios people are complaining about don't sound at all like your definition.

That's part of the problem, yes. DevOps started off with reasonably laudable goals: to promote a methodology whereby development teams and operational teams were tightly integrated in a way that made operational and deployment issues part of the development process: development would be driven by the need to deploy useful functionality, not just create it. That way, you didn't have a discontinuity where things were programmed, then someone would have to figure out how to actually deliver that bunch of code.

The problem which the author of the article references is that this often gets perverted from the original laudable idea of teams of developers and operations people working together, to requiring every single DevOps person being equally qualified to do everything, and then from there pushed even further to many companies creating DevOps positions where those DevOps people are literally doing everything, and not just knowledgeable at those things.

There is no question that a programmer that understands SQL or database architecture or storage systems or high performance networking or internetworking or virtual hypervisors is a more valuable programmer. They can use that knowledge to guide their development, write better code, and communicate better with the actual DBAs and network engineers and sysops and hypervisor admins. But when management types start to think that the best way to do things is to hire DevOps qualified people to just randomly do everything without any focus or specialization, that's when the myth of DevOps overtakes the reality of DevOps and begins to create real problems.

I don't honestly know to what degree that is pervasive in the industry: I haven't seen too many examples of it myself outside of certain high profile ones (the author mentions Facebook). If it is trending upward, I think its a bad trend. But to the extent that I see companies use DevOps correctly, as the glue-people to interconnect individual development, operational/deployment, and quality assurance teams, I think its a positive. But I agree with the article author that actually *replacing* developers, QA people, and operational people with DevOps people universally would be a Bad Thing. I just don't know if its actually really happening