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.'"
What DevOps movement? (Score:5, Interesting)
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.
Understanding each other's work is key (Score:5, Interesting)
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.
Someone doesn't understand devops. (Score:5, Interesting)
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.
On the other hand, most devs do not get ops (Score:4, Interesting)
A problem I have run consistently around is that developers rarely understand system administration, and operations in general. It makes their software suck a lot more. This is even more true with the Java-crowd, many of which cannot even use a commandline. The more this gets fragmented, the more people get specialized, the more problems arise in architecture, design and implementation, up to and including software that cannot even be deployed because of misconceptions on the developer's side.
It's a Great Learning Experience (Score:5, Interesting)
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.
Re:This role exists in any non-software business. (Score:4, Interesting)
What sibling said... I've seen companies that refuse to have a DevOps position, but yet hire "System Engineers" that basically do the same damned thing.
The biggest danger I've seen is in trying to silo such a position. I actually prefer having the freedom to whip up port channels on my own switchgear and having my own vlans/IPs to play with. I need free reign over an independent and complete environment for QA and dev use (so I don't have to put in a change request and then wait a week just to, say, add one IP addy to a NetApp SAN's NFS export ACL on some dark and early Sunday morning.)
I've done this job in a siloed company environment before, and quite frankly it sucks. You sometimes spend literal weeks waiting for one stupid VM that you could have cloned off yourself in less than 10 minutes, and configured in less than five more. I remember waiting almost a month while two different IT departments argued over how they would route a simple outbound rule over multiple firewalls whose path crossed the realms of their two departments... meanwhile having the devs wait alongside with me until the parties in question got done measuring their penises and found a solution (it took a pissed-off client, and a subsequently scared VP to threaten some jobs, which finally got them to STFU and work something out).
Devs and QA alike need someone who can quickly cut through the bullshit and red-tape, understand what it is they do (and more importantly, what they need and why they need it), and as someone aptly stated, "make shit work."
Re:whine (Score:5, Interesting)
DevOps is all about creating dangerous conflicts of interrest.
DevOps may be acceptable in a startup where there simply aren't enough people to separate the roles.
As soon as there are enough people, the roles should be separated.
A devops guy is basically judge, jury and executioner of his own work; it's destined to fail.
Re:Author is dumb (Score:2, Interesting)
I think anyone who's developed and tuned systems at reasonable scale tends to have skills not just across the software stack, but across the infrastructure as well:
That means familiarity with the features and limitations of many different storage solutions (SAN, NAS, distributed fabrics of local disk nodes all with spinning and solid state, not to mention the Amazon flavors) , networks, bare-metal boxes, hypervisors, OS's, clustering solutions, a multitude of languages, databases (relational, document, NoSQL, etc.), statistical modeling techniques, COTS and OSS products, CM and dev environments, as well as specialized hybrids of all of the above. You may not need to be a SAN administrator, but you need to be able to know IOPS and see if you are constrained by disk or network . You need to know how to monitor memory and CPU across all layers of the infrastructure, read heap dumps, stack traces, etc to see what's what. And then know a multitude of languages, design patterns and anti-patterns, methodologies to go from idea to solution in a disciplined cost-effective way. You need to be able to communicate all of the above internally, externally to both vendors and customers, and then make it understandable to the chief technologist, senior developer, recent-grad programmer, CEO, sales guy, and the middle managers in-between all of the above, not to mention your stay-at-home-with-your-kids spouse who wonders what you do all day. I've got plenty of real-world experience and think the whole concept of developers being put out to pasture at 40 is complete and utter bull if you are smart and reasonably hard-working. Us 10x full stack developers who do it all get paid pretty well and haven't ever had trouble finding interesting work where people need the best to solve the hardest problems.
Son, get off my lawn.
Re:whine (Score:5, Interesting)
DevOps is all about creating dangerous conflicts of interrest.
No.
And I'd even go so far to say that we need MORE conflicts of interests.
A software company is full of conflicts if interrests. You have the sharholders who want money, sales who care about release dates, customers who request a feature, devs who know that that feature will have unpleaseant side-effects that the same users would not accept and so on.
"Resolve" those "conflicts" by completly seperating them into different roles, and you have a company where departments will fight each other to the bone and management will be busy with conflict resolution instead of actual work.
You need to have people inbetween those branches who know how to make them work together.