How 'DevOps' Is Killing the Developer 226
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.'"
whine (Score:4, Insightful)
Re:whine (Score:5, Insightful)
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 role exists in any non-software business. (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Oh please... (Score:4, Insightful)
You don't force your brightest people to take on additional roles - that is the whole point of a devops team in the first place. Making developers argue about deployments and sending builds to QA and managing your GIT server and development and QA databases and managing your bug tracker is exactly what your developers should *not* be doing, especially if those scripts necessarily have to be in a different language than your application. Sure, your lead developers and architects work with the devops team to support them so they can in turn support you, but that's as far as the relationship goes.
The way we used to do it, where every senior architect is also responsible for all of those other functions (and has to take the time from his team members below him to help build all that out), is exactly how you stop architecting your software: your leads spend so much time trying to automate the drudgery they aren't improving the app.
They aren't improving the app because all of their brainpower is no longer focused on the *customers'* problems, but rather their own and their teams. That isn't a good use of their time. Hiring smart people who need to understand the application and its environment, but are good at scripting these other languages of automation, frees up your team leads to doing what they did before and do best: focus on the application and getting the team to produce the code that serves the customers' needs.
Just because you can doesn't mean you should (Score:5, Insightful)
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:whine (Score:5, Insightful)
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 (Score:5, Insightful)
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.
DevOps (Score:1, Insightful)
Yet another buzzword invented by some CIO/CTO somewhere in an effort to consolidate multiple job roles and eliminate warm chairs. No surprise that its genesis seems to be in the startup world.
"DevOps" is a fucked up amalgam of the developers, the DBAs, the system admins, the mail admins, the storage and backup admins, and sometimes the field techs... All to extract more work from fewer people for less money.
Re:Author is dumb (Score:5, Insightful)
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... (Score:5, Insightful)
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
Re:whine (Score:5, Insightful)
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 (Score:4, Insightful)
My experience on this is that you need 'DevOps' to run the development environments but you need production ops to run, eh, production.
DevOps people don't necessarily have good understanding of the underlying issues of the production environment. There are several issues revolving around this: Security, availability, scalability, etc. As an example is dev who can secure the application but not the platform (database, web servers and so on).
Good handovers between the two are the key for success. If 'DevOps' changes the development environment in a significant way this needs to be taken into account when moving the version to production. Oh, you upgraded the database in development environment? I guess that explains why RTP failed and we had to roll back.
Some changes may be very simple to do in development environment, while difficult in production environment. Need some extra disk and upgrade your database backend? Sure, just get it done in the development environment but there may some issues when doing that in production environment; you may need unacceptable amount of downtime, etc...
Re:whine (Score:5, Insightful)
No, the point of "devops" is getting your employees to do two jobs.
Re:whine (Score:4, Insightful)
helping the "brightest pure programmers" understand why the cool solution they developed is a POS in production
Absolutely. I was in a startup as a dev, and by necessity we were the operations guys early on. It was a financial service that needed to be running 24/7, and having to deal with "oh shit" moments while under the gun instilled the importance of writing software that was built for reliability, graceful failures, recovery, and error reporting.
None of this "brogrammer" shit or programmer "cowboys" or any of that other nonsense.
Re:whine (Score:5, Insightful)
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.
Developers are not the top of the food chain. (Score:3, Insightful)