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.'"
Python guru Jeff Knupp should go find a job where he can program, and not worry about ops. Simple solution.
"First they came for the slanderers and i said nothing."
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.
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.
I'm a good cook. I'm a fantastic eater. - Steven Brust
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.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
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.
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.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
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?"
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Several problems with the original article. Jeff makes the assumption that Developers are at the top of a totem pole and all others are below this developer hierarchy. This is the problem with a lot of younger developers, most who are jumping into development with no structural background in the operating system or real production operations. This premise leads developers to think they are superior to everyone, rather than focusing on building applications that must run in an operational context of being well-behaved in the environment they run, and allow for maintenance work of the operations environment. This is why you see anecdotal articles coming out that talk about the frustration and friction between developers and operations people. The truth is, most developers will be better developers if they learn a little more about how their app will work in a production environment. They will build better applications because they understand the environment better. Your architecture should be loosely coupled, that is, it should not stack up on a single server but rather be broken up into smaller components that can be built for scale across multiple machines and be able to fail over to redundant systems. Ops people will be more than happy to help get you there, but you need to think about how your app will fail as much as how it will work properly. The developer also needs to stay away from dictating specific languages -must- be used to run operations. Rather, they need to understand that operations is best suited to a polyglot of different kinds of tools and languages, using the right tools and wares for the job, not being dictated in some kind of nanny state that says you must use this language or that for operations and all others are to be thrown out. All too frequently startups get hung up on dictating operations people must use Python or Ruby or the ops dude is a total loser. This is the kind of arrogance that shows how little most developers really know about operations. Any of the more popular tools should be available to the DevOps person so they can get things done, and developers should stay away from being nannies. In classic UNIX operating environments the system administrator is/was god, followed by an allowance to use the system granted to developers, database admins, etc. Applications have always been guests inside most Linux/UNUX-based systems, even Windows treats applications for what they are, programs that run inside the operating system. This has always been the premise of modern UNIX-based and even Windows-based environments. Ops people follow this naturally, but typically run into developers that don't want to follow the rules. Ops people expect you to write a well-behaved application. Developers expect an operations environment that runs their application without getting in the way. These two goals can be easily met if both sides work together and allow each side to exploit the system, but everybody has to allow the freedom to make things work best for the goal of building better systems.
Tim