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
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.
I am primarily a developer but I also like to understand the big picture, including software design and UX but also system administration, infrastructure, hardware architectures, and everything else that *directly affects the software I develop*.
Deep understanding of the big picture is key to developing quality software, IMO. You need to understand what comes ahead of you (requirements, business needs, etc) and where your work is headed afterwards... The best way to understand it is to wear these hats from time to time or have previous work experience in those fields. When recommending candidate for developer positions, someone who has system administration experience is a bonus.
Yes, many days I need to take on multiple hats and switch gears as shit comes up in prod and I need to fix a config on production servers or assist whoever has the hands but lack the knowledge. That's the start-up culture I guess, even though I work for an established 100+ year old company.
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
I essentially have this kind of role within my organization. I design, develop, deploy, and support small to mid-tier systems (e.g., the planning system for a $XXXmio/yr global department, with 300+ direct users) while being one of my own customers, as I am actually a business planner (by role) as opposed to developer. I develop systems as a way to do my "day job" much more effectively. Typical tech stack would be Excel UIs, PostgreSQL data store, and whatever else I need in the middle (e.g., nodejs, tomcat, redis, whatever).
What I've found is that, in general, doing the right thing the "right way" is not worth the cost compared to doing the right thing the "wrong way". By definition, in either scenario, the right things is getting done. What most pure developers utterly fail to understand is that in trying to do the former, there is an overwhelming tendency to do the wrong thing the right way instead.
This is because, as Fred Brooks pointed out long ago--and as the "lean startup" movement is re-discovering today--for any non-trivial novel problem you cannot know in advance what the "right thing" is until you've actually tried to implement a solution. Brooks stated this understanding as the need to throw away the first try, and the lean startup movement is essentially defined by a corollary--you have to figure out how to try cheaply enough that you can afford to throw it away and try again (and again, and again if necessary), while progressively elaborating a robust definition of what the "right thing" looks like by using those iterations as experiments to test hypotheses about what the "right thing" is. Doing things the "right way" usually costs so much in time if not capital that you simply can't afford to throw away the first try and start over, or you cannot complete enough iterations to learn enough about the problem.
Now, I'm not saying that you should be totally ignorant of software engineering best practices, design patterns, etc. What I am saying is that there is a limit to how effective you can be in reality if you live purely within the development silo. Having a "DevOps" role (granted, self-imposed in my case) has been one of the best things that's ever happened to me as far as making me a better developer, right up there with the standard oldies like writing your own recursive descent parser and compiler.
In short, it is commonly-accepted wisdom among programmers (for good reason!) that you are more effective if you actually understand the technology stack down to the bare metal or as close to it as you can manage (even if only in abstract-but-helpfully-illustrative examples like Knuth's MMIX VM), and that this understanding can only be gained via practice. It should be obvious that the same is true in the other conceptual direction through deployment and end use.
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.
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