> Originally they both described a set of principles, an ethos, not a specific role.
The way I understood DevOps (back from the first DevOps Days in Ghent) is that clear separation of sysadmin and developer roles harms the process of software delivery and that developers should maintain their code up to production, and learn from the process.
It was, in a way, a critique of the project-driven business where teams ship and jump over the board.
When it first started doing this I found it be to more tear down the moat many developers like to put between them and the rest of the business. Basically get up and go talk to QA, helpdesk, delivery, and marketing. Find out what is failing and fix that. Make sure those groups can use and maintain the code being delivered. THEN work on things that are new or champion those things that are broken to get fixed in the next cycle. That was devops to me.
Then it turned into this guy who can not really do anything. Can not really check in code because the devs do that (separation of duties). So you never get any real experience in the codebase. Can not make any decisions because the marketing/product owners do that. Can not really make better test cases as that is for QA. You can however help on the helpdesk they are short 3 people today. Then the meetings. Endless meetings upon meetings. Because your 'devops' you need to know everything that is going on and better have those statuses on the high priority items to be fixed. Oh and you are 'on call' so you can never really 'go home'. Then if something breaks all you can do is just call in others and make them fix it. Making you little more than tier 3 helpdesk. Useless paper pusher job with zero authority.
The problem is, however, that those two roles require different knowledge, skills, attitudes and mindsets, and so many (most?) developers don't really like sysadminning: you know, messing with VLANs, DNS resolving, packet routing, gluing two networks (one in Sidney, second one in New York) into one via VPN, watching disk quotas and memory limits, working around bugs in Linux scheduler, pinning CPUs, all that mind-bogglingly boring (but needed for smooth operation) stuff.
I enjoy making sure software works for people, the more people the better. If that involves all that sysadminning, I will enjoy that as well.
But most of my peers are oblivious to the fact whether their code will be used at all and are having fun filling their heads with complex abstractions right before spitting them on screen.
Yeah, that was it. And like Agile, it sounds good on paper.
Point is, once developers start doing support, they stopped taking those learnings and going back and developing better. Instead the organization just started having developers do support. But then, why are the support people these highly paid developers, lets change the role definition again to not need to code.
Seems like on-going title shuffle, around, we don't really want to pay to develop, why can't we get by with no-code.
The way I understood DevOps (back from the first DevOps Days in Ghent) is that clear separation of sysadmin and developer roles harms the process of software delivery and that developers should maintain their code up to production, and learn from the process.
It was, in a way, a critique of the project-driven business where teams ship and jump over the board.