Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How 'DevOps' Is Killing the Developer

Soulskill posted about 6 months ago | from the in-the-server-room-with-the-lamp-stack dept.

Programming 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.'"

Sorry! There are no comments related to the filter you selected.

whine (4, Insightful)

phantomfive (622387) | about 6 months ago | (#46763355)

Python guru Jeff Knupp should go find a job where he can program, and not worry about ops. Simple solution.

Re:whine (5, Insightful)

Anonymous Coward | about 6 months ago | (#46763389)

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.

Re:whine (5, Insightful)

Ice Station Zebra (18124) | about 6 months ago | (#46763523)

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 (4, Insightful)

mlts (1038732) | about 6 months ago | (#46763661)

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.

Re:whine (0)

Anonymous Coward | about 6 months ago | (#46763659)

except for every programmer job there are 50 devops jobs

because its all getting turned into glue

Re:whine (4, Insightful)

Penguinisto (415985) | about 6 months ago | (#46764029)

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 (1)

agileinfoways.com (3618017) | about 6 months ago | (#46764305)

Python guru Jeff Knupp should go find a job where he can program, and not worry about ops. Simple solution.

I think today many different forces are placing new demands on change and release management, which are stretching traditionally organized teams in a myriad of ways. There is pressure from the development team to reduce controls around code moving from development to unit testing, to user testing, to system testing, to staging. And there is pressure from the business side of the organization to reduce cycle times to keep pace with competitors. In addition, business is making demands around governance and auditing, asking for greater visibility, accountability and traceability.

You want a job? You do what I tell you. (-1, Troll)

Anonymous Coward | about 6 months ago | (#46763365)

It's amazing that people think they somehow have this right to do whatever they want. Chances are your not better then everybody else and you should be burdened with real work sometimes that you just don't like. It's called a job. Not your fun playground to do what you please with.

Re:You want a job? You do what I tell you. (0)

Anonymous Coward | about 6 months ago | (#46763509)

Sure thing, it's your money to burn. Can you pay me 100K+/year as a developer to be doing stuff that a DBA should be doing for 70K/year? Or a Sysadmin for 60K/year?

Re:You want a job? You do what I tell you. (0)

Anonymous Coward | about 6 months ago | (#46763689)

100k 170k

Well - that's the KEY now though, isn't it? (0)

Anonymous Coward | about 6 months ago | (#46763827)

Do something you really like, and get PAID for it... makes that whole "that's why it's called work - you're not supposed to like it" deal that folks that might have made less than optimal choices, end up in.

That goes for any job - doesn't have to necessarily be all DRUDGE dreaded work, but a job instead, for any field, for any person.

Ever heard "Happy Workers are GOOD workers"? They are. I've had my time in mgt., they are. I've been on the other side, Thing is, we all answer to someone. Ultimately the one that owns the place or a board full of them, etc.

(Have we all had a "shit job"? My guess is yes. I have. I get out of them fast, or just avoid them - unless I need the money, REALLY bad that is. Then it's welcome to the world of "you have no choice"... happens. For me, when I was younger really. Didn't have good ideas a couple times on what I was looking for, OR what I wanted really...)

APK

P.S.=> It's a lot of good early guidance in life or examples mostly you hopefully got the benefit of being exposed to as a young one really - it all starts @ home etc. that helps you, imo, find that right area from examples you see...

... apk

This role exists in any non-software business. (5, Insightful)

fractoid (1076465) | about 6 months ago | (#46763417)

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.

Re:This role exists in any non-software business. (1)

CAIMLAS (41445) | about 6 months ago | (#46763869)

Exactly.

This "there is no role for devops in a mature company" attitude cries back to the age of isolated business units with isolated departmental goals, often where sales sells products that don't exist and engineering produces products nobody wants. The money to run the company will come from somewhere!

In short, developers don't want to dogfood, because that's hard. It's much easier to not challenge yourself with divergent ideas from what you and your brainfund coworkers cook up: after all, developers made it, so it must be good.

And yes, devops is an integral part of dogfooding. It makes sure the left hand is talking to the right, Support is able to effectively move issues laterally, operations can effectively provision IT infrastructure budgets, and Engineering can focus on the real issues that impact the product. It's called teamwork. If you can't get this part done right - at the very least, making sure your product works in an operational capacity internally - how can you expect it to be a commercially viable option out of house?

Re:This role exists in any non-software business. (1)

Anonymous Coward | about 6 months ago | (#46764125)

One of the dumber moves our company made for quality was splitting maintenance from development. Once the developers stopped taking level 2 calls for the shit they wrote, they had no incentive to write less shitty code. This shit's continued for 15 years.

10 years ago we got more stupid, as the HMFIC started splitting development jobs into thinner slices, removing testing and then deployment from the development teams; and then they went off the rails stupid, splitting off tasks that don't even make sense: packaging, deployment scheduling, app security (WTF?), architecture, design (WTWTF?), and having analysts, testers, architects, engineers, coders, and PMs all reporting up through different pyramids. A software project progresses through over a dozen phases and tollgates and checkpoints and reviews and committees. They wanted to build a "software factory model", to be exactly like the crappy outsourced vendors we hired who can't write 10 consecutive lines of working code. The stupidest part is the HMFIC would fire your ass if you didn't believe in the sanctity of the model, meaning every single manager from the line managers on up lies to their supervisor, telling them the fires they see are just sunshine and the shit they're smelling is roses. They'll only hire people who agree to repeat this insanity, so we have hired very few competent people in this decade. So nothing works at all, but nobody says anything bad. Because stuff doesn't work, they keep adding managers to do more oversight, and we're now at about a 2:1 ratio of workers to managers. They won't acknowledge that it now takes half a year just to fix a bug. HALF A FUCKING YEAR TO FIX A SIMPLE FUCKING BUG. And not just any bug: every bug takes that long to fix.

Now they're thinking that by adding a few more review steps that happen every two weeks and hiring some Scrum-certified contractors to be project managers, we'll somehow become Agile.

Dilbert would find enough frustration to go postal in our shop.

Re:This role exists in any non-software business. (2)

Sarten-X (1102295) | about 6 months ago | (#46763921)

From TFS:

...it has no place in bigger, more established companies.

I've worked at a Fortune 100 company, who was looking to add a DevOps team, because our development and our deployment teams weren't working together as smoothly as we'd have liked. The development teams didn't know anything about the hardware their (very hardware-specific) software ran on, and the hardware teams didn't know what parts of the software needed testing on new hardware.

Of course, it's ridiculous to ask the hardware guys to be present at all of the software meetings, and vice versa. DevOps fills a role bridging the gap. Outside of IT and platform-agnostic software development, the "ops" part can be a customer-facing role. In the shelter of software development, any incompatibilities can be blamed on hardware, rather than the real underlying cause of "poor testing across platforms"

Re:This role exists in any non-software business. (2)

Antique Geekmeister (740220) | about 6 months ago | (#46763943)

> This sysadmin/scripter/system architect/DBA

And then they stop doing _any_ of the tasks well. They don't show up for planning. they don't document their code, because "it's self documenting" or "documentation is unrelable". They say "Just Google It" when most of what is on Google about the task is _wrong_ and written by people who aren't aware of the subtleties. They refuse to mentor, because it keeps them away from the meetings where they can soak up and interfere in _every single groups's projects_ by citing standards that are only in their head, or worse, are only in the mental image of what other people remember they said once about something else.

One of the great pleasures of my professional life is finding these people and educating them in how _not_ to be a micro-managing block to everyone's work: it involves actually documenting the _working procedures_ for daily tasks so other people can do them. Many of them are afraid of the loss of control or possible errors, but the improvement in speed of daily procedures is enormously satisfying.

Re:This role exists in any non-software business. (3, Interesting)

Penguinisto (415985) | about 6 months ago | (#46764113)

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."

Nothing new here (4, Insightful)

nitehawk214 (222219) | about 6 months ago | (#46763427)

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.

Re:Nothing new here (2)

DaveAtFraud (460127) | about 6 months ago | (#46763693)

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.

If you think the sysadmin who can program or the programmer who can admin a system is bad, you should have seen what happened when they gave Visual Basic to a subject matter expert (SME) and said, "You can program!" Agggghhhhhh!!!!!!!!

Cheers,
Dave

Re:Nothing new here (1)

nitehawk214 (222219) | about 6 months ago | (#46764023)

I have seen far worse. Full on applications written in Excel VBA by those SME's, MBA's and Finance (degrees? I am not sure). And those people that somehow thought that:
A) they weren't shit and
B) they were now programmers and the job was so easy, why do we pay you assholes...

You can figure I did not stick around that job for long.

Re:Nothing new here (2)

Penguinisto (415985) | about 6 months ago | (#46764139)

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 think the problem is in mis-defining the role. A DevOps can write code at a junior level, but you don't want one doing anything more than simple modifications and/or workarounds. He can also do most of the infrastructure bits of IT at an experienced level, but you should always have him in close communication with the senior security admin, the senior network admin, the senior storage admin... this is so that he doesn't wind up going all cowboy on the infrastructure just to recover from an outage, or worse, do it just to meet an artificial marketing-induced deadline.

Re:Nothing new here (1)

pete6677 (681676) | about 6 months ago | (#46764165)

Funny how my company is going in the opposite direction. They want to get developers out of the production environment completely, and have an ops team do all of the support and maintenance. I for one am glad to see this happening.

Overly broad (0)

Anonymous Coward | about 6 months ago | (#46764259)

All DevOps teams are not the same. I work for a large and very much not cheap company, and while we do some minimal sysadmin work to develop a product and get it rolling we ultimately hand off the systems to IT + developer teams to maintain long term. I would say that system administration is less than 10% of my job.

Author is dumb (3, Informative)

w_dragon (1802458) | about 6 months ago | (#46763429)

Full-stack developer generally refers to a developer who can code the full software stack - UI, middleware, and backend. Also lots of QA people can code - automated testing is mostly coding - and lots of developers can't test at all. Author needs a bit more real-world experience.

Re:Author is dumb (0)

Anonymous Coward | about 6 months ago | (#46763569)

"Full Stack" development is great for learning, but is not something I would suggest as the norm. As a systems architect, I need to figure out how each part should fit and how it's implemented. If you don't understand the full stack, you can't correctly design it.

Re:Author is dumb (0)

Anonymous Coward | about 6 months ago | (#46763591)

Author needs a bit more real-world experience.

I think the author's got it in the bag. I'm a senior developer at a 21 year old startup that does C# thick clients over Microsoft SQL back ends. All of the developers here are expected to do all of the release management, DBA and sysadmin duties. Despite knowing far more than I want to about SQL Server's indexes and statistics, parameter sniffing, query planner, plan caching, etc., I consider myself to be a pretty shit DBA. I know that my company would be far better served to hire a real DBA that can handle the maintenance of the existing servers, do log shipping and replication effectively, do upgrade planning, do capacity planning, and beat the shit out of us developers for writing dumbass SQL. Despite all of the issues we keep telling our managers about they continue to *not* hire a DBA and use us as part-time DBAs. Doesn't matter whether that's because they're cheap or because they think we're awesome, it's a still a stupid thing to do.

Saving a few pennies (0)

Anonymous Coward | about 6 months ago | (#46763681)

By trying to save a few pennies, the company management shoots itself in the foot.
Although they don't know that.
I work at a medium size company where all teams have to do everything by themselves what creates an abundance of inefficiencies and people making the same mistake over and over again.
Having intra-team specialists for all those tasks would save so much time. money and trouble.

Re:Author is dumb (4, Insightful)

fractoid (1076465) | about 6 months ago | (#46763785)

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:Author is dumb (0)

Anonymous Coward | about 6 months ago | (#46763861)

It's a 21 year old company that still operates like a startup. i.e.: it thinks Agile is cool for all departments, nobody has job titles on their business cards because that would pidgeon hole them and all sorts of other startup-related crap.

Re:Author is dumb (1)

Ksevio (865461) | about 6 months ago | (#46763951)

Reminds me of an email I got from a recruiter today:

These units run as start-ups that share the same code base and computing environment, combining the excitement of a small firm with the stability of a larger one.

Because the beauty of startups is having a massive legacy code base that requires talking to several teams in order to change.

Re:Author is dumb (1)

fractoid (1076465) | about 6 months ago | (#46764013)

Oh no, not at all! The beauty of startups is having motivated, talented people willing to work long hours for peanuts!

Oh you mean the beauty of startups for the *employees*... :P

You might do a disservice (1)

rsilvergun (571051) | about 6 months ago | (#46763431)

but hey, free project management? Sign me up!

Seriously though, I am seeing more and more companies pushing to get more productivity out of their work force in an effort to keep the stock price where they need it....

DevOps is awesome (1)

Anonymous Coward | about 6 months ago | (#46763447)

All those configuration management scripts and orchestration tools are insanely helpful in development and testing and it's almost a bonus that you can use them in production deployment. Aside from that, nothing will help when you have bad human management. You still need sysadmins and especially DevOps sysadmins with programming chops that can fill in the production side of the picture.

Context Switching (1)

Anonymous Coward | about 6 months ago | (#46763469)

If people realized the cost of context switching on doing development, I suspect they would be much more loathe to require such context switching for Ops, and possibly not even for being a "full stack" developer.

Oh please... (3, Insightful)

acroyear (5882) | about 6 months ago | (#46763471)

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.

Re:Oh please... (1)

Dynedain (141758) | about 6 months ago | (#46763511)

Amen amen!

We have dev ops, and I RESPECT the guys.

Why?

Because I'm busy solving the client's problems, and I have developers underneath me building databases, front end templates, integration platforms, CMS implementations and the works. I DON'T WANT them patching AWS cloud servers for Heartbleed because THEY SUCK AT IT. Likewise, I don't want an IT guy who just installs patches and walks away. My IT department acts like that, and because of them, I still don't have VMWare and test machines in the office even though they were approved 2-3 months ago.

I want people who can setup Git and Jenkins without handholding or wasting tons of time. I want people who can manage security and system updates. I want people who can figure out and get the right versions of Python, JVM, or NoSQL-DB-of-the-month installed without micromanaging. DevOps is an incredibly valuable role if you find the right people to do it.

Hint: If it requires interfacing with the client, it probably isn't a DevOps task.

Re:Oh please... (2)

kwbauer (1677400) | about 6 months ago | (#46763665)

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.

Re:Oh please... (4, Insightful)

dnavid (2842431) | about 6 months ago | (#46763819)

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

It's just like when agile went hip... (1)

jopsen (885607) | about 6 months ago | (#46764091)

The problem that others are having with DevOps is that they seem to be defining it differently than you are.

It's like agile... when it became hip to be agile, some people started reading thick books about it - at which point - the point is missed :)

DevOps is possible because you can rely on hosted services, like github, travis-ci, heroku (the whole push-to-deploy movement), EC2, AWS S3, Azure table Storage, and various other vendors like CloudAMQP, Heroku hosted postgres, etc...

All of these hosted services means that there is much less administration and maintenance, plus, these services can be provisioned with the push of a button, rather than filing a bug with IT and waiting 3 months for a result.

The problem is that some people misunderstand DevOps, and miss the point just like some people did with agile development.
Also just like agile development, DevOps isn't the right tool for everything.

So, nothing new...

Re:Oh please... (0)

Anonymous Coward | about 6 months ago | (#46764121)

The guy that wrote the article sounds like he got stuck as Build Bitch. There's nothing new about that. It happens, and has been happening since the dawn of release and deploy systems.

Be that as it may DevOps is awesome until it's not awesome. Usually there is a natural progression where the dev team starts up their own build, repo and test suite. Maybe they'll rig up their own SQL/NoQL solution too. If it's cloud based they are likely started the chef instances. Eventually this system gets baked well enough that it's handed off to an ops team. Nothing really new to see here outside some of the fancier automation tools we have these days.

Where it goes off the rails is when DevOps team becomes a burden on the process. Things I've observed:

I've seen ops teams try to dictate the programming stack, down to library level.
Cock blocking the architecture teams because the carrots and sticks were setup to avoid change.
Poorly performing developers shuffled over to DevOps teams to become poorly performing DevOps resources.
Process overload.

Just because you can doesn't mean you should (5, Insightful)

putaro (235078) | about 6 months ago | (#46763475)

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:Just because you can doesn't mean you should (0)

Anonymous Coward | about 6 months ago | (#46763641)

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.

Depends on how you define QA, I suppose. In our world the developers should be writing unit tests for all of their code (TDD or not) and QA should only be doing functional testing.

Re:Just because you can doesn't mean you should (1)

CodeBuster (516420) | about 6 months ago | (#46763853)

Most people are a lot more comfortable and eager to break someone else's code than they are their own.

Not me. I'm just as merciless with my own code as I am with others' when writing tests. Proper testing involves taking on the role of the malicious agent who is actively trying to break the code, feed it bad inputs and generally muck up the works. If the code passes those tests then it stands a much better chance of rolling with the punches in the real world of production.

Re:Just because you can doesn't mean you should (1)

CAIMLAS (41445) | about 6 months ago | (#46763899)

Deveops types aren't the kind of people to be crawling around under desks or helping directly to push for a release milestone.

They're the go-betweeners, sort of a cross between senior sysadmin and development project management assistant. They are the internal toolsmiths, depending on the blacksmiths to produce effective metal so they can hone the tools for the carpenters' needs. They are broadly skilled and know how to at least muddle along in both a developer and a sysadmin job, but prefer the big picture of orchestration. They're the ones who figure out where the shortcomings are, and are broadly skilled enough to jump in and provide possible avenues and solutions, seeing where one side can't fix a problem, and the other may have a solution.

Re:Just because you can doesn't mean you should (1)

Antique Geekmeister (740220) | about 6 months ago | (#46763965)

I jump under desks! But I'm a very, very senior technologist, and I spend a lot of my time _teaching_ people how to do these things.

What DevOps movement? (5, Interesting)

PJ6 (1151747) | about 6 months ago | (#46763481)

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.

Re:What DevOps movement? (1)

Cytotoxic (245301) | about 6 months ago | (#46763601)

I was going to say something similar. There are a lot of people who don't want to be kept in a box, doing only one thing all day. I used to hire those people specifically - I found it worked well for our culture. Plus, I personally get bored with too much of the same thing. I love coming up with a cool SQL trick that cuts the cost of a query by 99%. It is fun to watch something complete in 2 seconds that was taking 15 minutes before. But I wouldn't want to do that all day, every day year after year......

Different strokes for different folks. Not every developer wants to be pigeon-holed into coding web-server middleware all day, every day.

Re:What DevOps movement? (0)

Anonymous Coward | about 6 months ago | (#46763707)

There are a lot of people who don't want to be kept in a box, doing only one thing all day. I used to hire those people specifically

There's one thing about cross-disciplinary training, and another thing where your mailserver is falling over and a major customer is screaming about how they were promised a major feature today and they're going to walk if they don't get it... and your jack-of-all-trades is demanding that you put your priorities in writing to cover his ass when one of the two doesn't get taken care of.

Re:What DevOps movement? (1)

canadiannomad (1745008) | about 6 months ago | (#46763915)

another thing where your mailserver is falling over and a major customer is screaming about how they were promised a major feature today and they're going to walk if they don't get it... and your jack-of-all-trades is demanding that you put your priorities in writing to cover his ass when one of the two doesn't get taken care of.

I think you just summed up 90% of my job!

Re:What DevOps movement? (1)

phantomfive (622387) | about 6 months ago | (#46764119)

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.

Oh yeah, that's exactly what I look for in a job.

Re:What DevOps movement? (0)

Anonymous Coward | about 6 months ago | (#46764299)

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.

IBM defined this model - the Chief Programmer.... see this: http://c2.com/cgi/wiki?ChiefProgrammerTeam

Largely ignored because is difficult, bordering impossible, to recruit a Chief Programmer .... unless you happen to be one and start the business :-)

Understanding each other's work is key (4, Interesting)

ghn (2469034) | about 6 months ago | (#46763483)

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.

Re:Understanding each other's work is key (2)

ghn (2469034) | about 6 months ago | (#46763521)

And regarding the "Totem Pole" argument in TFA: That is utter BS. I've seen many so-called "developers" unable to perform basic DBA or QA jobs. That is why most large company employ specialist in these positions, to cover the fuck-ups of the developers.

I've seen developers who's first reaction when a complex SQL query is taking ages to run is "I will call my old pal in XYZ dept who is a DBA" before even running an "explain" query to debug their index-less octo-way join with 12 sub-queries.

Re:Understanding each other's work is key (1)

Dynedain (141758) | about 6 months ago | (#46763545)

Your value isn't in being the guru. Gurus get replaced because of the risk in only one person understanding how things work.

Your value is in being proficient enough that you can jump in and get up to speed in different roles, but have a general understanding that lets you step back and see the big picture.

Yes, getting your hands dirty is different pieces is key to this, but being the leading expert in each individual piece is the road to being pigeon-holed.

Not working IT anymore but... (0)

Anonymous Coward | about 6 months ago | (#46763487)

As I remember it, when one of our programmers had additional roles, we the ops team had to bug them about those roles... IE "Hey bob what is going on with these wifi scanners, with a web interface to our DB, on your desk. I have to send two out to the warehouse." Bob would then loose his thread of thought on improving the web interface and probably some details on the overall program he had stored in his head. Now Bob has to take time to get back to where he was and if someone interupts Bob again... Bob eventually becomes less productive and frustrated. Frequently if Bob is a good programmer, he quits.

DevOps vs DevOps (0)

Anonymous Coward | about 6 months ago | (#46763497)

My own understanding is that DevOps can be two things:

1. All in one folks who write the software, deploy it, and make sure it's running at all times - bad.
2. Operations folks with a more development mindset (i.e. with development background) that use tools like Chef and Puppet to turn their infrastructure into version controlled code - good.

It appears he is talking about #1, but it shouldn't be mixed up with #2, which can be very very good if done correctly.

Posting as A/C because I haven't posted before and have no street cred...

Posting as AC... (1)

JustShootMe (122551) | about 6 months ago | (#46763525)

Yeah, you put a coherent thought together and actually contributed to the discussion.

Keep that up and you'll have no street cred on Slashdot at all!

Re:DevOps vs DevOps (1)

BradMajors (995624) | about 6 months ago | (#46763777)

The basic problem is developers are incapable and do not want to produce software that actually works and expect "lower level" people to fix their work.

Someone doesn't understand devops. (5, Interesting)

JustShootMe (122551) | about 6 months ago | (#46763507)

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.

Re:Someone doesn't understand devops. (2)

mortonda (5175) | about 6 months ago | (#46763563)

Devops is even more than this, it also means applying common change management that is common in source code development to operational configuration, using tools like chef or puppet. It's scary how much "cowboy configuration" there is out there, and yet in the programming world, "cowboy coding" is frowned upon.

Re:Someone doesn't understand devops. (5, Funny)

russotto (537200) | about 6 months ago | (#46763621)

It's scary how much "cowboy configuration" there is out there, and yet in the programming world, "cowboy coding" is frowned upon.

Oh yeah, it's frowned on. Every senior developer will sternly tell you that "cowboy coding" is a terrible idea, then they will saddle up their horse and ride away.

Re:Someone doesn't understand devops. (1)

Baby Duck (176251) | about 6 months ago | (#46763807)

Awesome quote! I will attribute you, russotto!

Re:Someone doesn't understand devops. (0)

Anonymous Coward | about 6 months ago | (#46763973)

Saddle? We don't need no stinking saddles!!! We'll just invent a whole new horse riding paradigm, with none of the flaws of saddles!

Re: Devs never learnt maintainable until tried (0)

Anonymous Coward | about 6 months ago | (#46763675)

Wholeheartedly agree with you.

A big lesson I learnt in DevOps situation is to properly log the tricky bits of the code logic so they can be easily tracked and troubleshoot in production environment. In a complex solution, if you have to look into the source code to figure things out, there is a gap in your code's maintainability.

It is sad that many devs just don't get it until they are forced into the support role and frustrated ( as I was ) in lacking of critical supportable data. Well, you don't (oh, please don't) get a debuggable version on production and you don't have your favourite IDE to step into...

Re:Someone doesn't understand devops. (0)

Anonymous Coward | about 6 months ago | (#46763687)

Way to miss the point. Entirely. The entire point of the rant was that companies are saying "fuck devops, developers can just do cowboy deployments whenever they need to in order to make sure that they are agile as fuck and I'm sure a ruby on rails developer can figure out this whole security thing and I get to keep the devops salary as my bonus."

Re:Someone doesn't understand devops. (0)

Anonymous Coward | about 6 months ago | (#46763779)

I was once a devop before the term existed. I mosty do Java / J2EE development, but I also did Solaris and Linux system administration .. even down to setting up disks on a Sun StorEdge disk array and setting up backups to tape before it gets shipped to off-site storage, coordinating with the data center for firewall rules ( e.g. setting up VPNs to mobile phone carriers, clustering and ensuring multicast packets are working, etc ) That was with a startup about 7 years ago.

With a large and more established company that I am working for now, operations is completely separated from development. Whenever a new system is deployed, I try to think of what operations will need to know. Only problem is, some IT ops are less knowledgeable than what I was hoping for.

In any case, maybe the author ( and probably me as well in hindsight ) is complaining .. you are effectively playing two roles .... but you only get paid the same amount as an ordinary developer. Nowadays, if I was offered a DevOps role, I would expect the package to be higher than if I was just doing pure development.

Cross training (1)

PPH (736903) | about 6 months ago | (#46763515)

The best developer is one who puts stuff together that 'ops' people (users, admins, etc.) can work with. And the best way to get such developers trained is to give them some experience on the other side of the fence. Yes, in a large organization there is going to be less crossover. But its still a good idea. Some people won't like being admins. Some will really take to it. Its up to management to properly allocate resources and keep their people trained and familiar with adjoining organizations needs.

If you absolutely don't want to do any administration tasks, that's fine. But its a rare developer who doesn't throw a fit when management takes their admin/root privileges away on their own workstation.

Re:Cross training (2)

Dynedain (141758) | about 6 months ago | (#46763657)

If you absolutely don't want to do any administration tasks, that's fine. But its a rare developer who doesn't throw a fit when management takes their admin/root privileges away on their own workstation.

It's legitimate for a developer to throw a fit. They should have admin access on their local box. There's an insane number of plugins, libraries, and frameworks they may need to install or test to determine if it's the right fit for their deliverable.

However, I fully expect DevOps to question every single add on and make the developer justify it before deploying to production. Just because I as a Dev want Ruby for compiling SCSS to CSS on my local machine to save me time, does not mean Ruby needs to be installed on the production environment. That's what build servers and deployment scripts are for.

SysOps on the other hand is far too prone to blanket say "No" or "We only approve this one obscure outdated fork of the package you want."

DevOps is the perfect position to reconcile developer wants with checks and balances against actual needs and responsible deployment.

That's a bad idea (1)

cold fjord (826450) | about 6 months ago | (#46763533)

Most developer's I've met have little interest in being Sys Admins, and even fewer of them had the background to administer a large complex site. (Not that they couldn't learn.) In a similar fashion not many Sys Admins are software engineers even if they are capable, even accomplished coders. They are different skill sets even if there is some overlap, and definitely a significant difference in emphasis. Temporary substitutes for each other at best.

On the other hand, most devs do not get ops (3, Interesting)

gweihir (88907) | about 6 months ago | (#46763555)

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.

 

Re:On the other hand, most devs do not get ops (0)

Anonymous Coward | about 6 months ago | (#46763711)

This is even more true with the Java-crowd, many of which cannot even use a commandline.

If I had a dollar for every developer I had to lead through basic use of SSH, I'd be buying a large island. Like Britain.

Really, though, DevOps is codeword for "fucktarded waste of time and resources". If your devs can't ask your sysadmins, "Hey, can we do this?" and get either "Yes" or "No, because..." in response; if your sysadmins can't ask and receive the same of the devs...

You need to fire people, because no Rightthink(tm) Process Magical Ponies will save you.

Don't confuse PROGRAMMER with Developer (0)

Anonymous Coward | about 6 months ago | (#46763589)

A programmer does code. A developer is the concept of those that make the end resulthappen. A programmer is one part. The most important part, of course, but developer does not mean programmer. And engineer is not correct. A computer programmer is exactly right.

Misunderstands what DevOps is about (0)

Anonymous Coward | about 6 months ago | (#46763627)

DevOps is not about reducing developers to doing mundane operations jobs, it's about reducing operations jobs through better software design so that they are no longer jobs, but things you spend a few seconds each day doing.

DevOps is all about removing the "full stack" that the author seems so attached to, and replacing it with functional minimalism that doesn't require a dedicate role just to manage the unnecessary and unproductive complexity we have in older systems.

DevOps doesn't suck for developers, it sucks for operators, who are left without a job. Good riddance.

So what are they supposed to do then? (1)

Warphammer (610896) | about 6 months ago | (#46763663)

Well, at least someone's finally admitting what it's all about.

It's a Great Learning Experience (4, Interesting)

nebosuke (1012041) | about 6 months ago | (#46763679)

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:It's a Great Learning Experience (2)

Todd Knarr (15451) | about 6 months ago | (#46763805)

The difference is between developers knowing the operations side and being the operations side. Developers need to know the operations side to know how to write software that Ops can install and manage. And they should be involved in the development environment and installation in the testing environment so any gotchas can be addressed quickly and the developers know exactly what happened and can go back and make sure it doesn't happen again (especially in production). And of course when things really go pear-shaped during production deployments it never hurts to have the developers on tap to tell Ops whether there's a simple, quick workaround that'll salvage the deployment or whether it's time to roll back until they can fix the problem. But those are a far cry from developers doing Operations support and administration work on a daily basis. Frankly they're two radically different skill-sets. They're related, sure, but having a developer doing Ops as a regular job is like having Kelly Johnson keeping a fleet of Piper Cubs in shape. Sure he can do it, and technically he can probably do it better than a regular mechanic, but in a month or so he'd be bored to tears and walking out to go work somewhere where they'd actually let him do his job designing and building planes like the SR-71.

Re:It's a Great Learning Experience (1)

nebosuke (1012041) | about 6 months ago | (#46764203)

I suspect there's a bit of a definition issue at play here (with all fault apparently being on my end, given some of the other comments in this discussion). In my mind, DevOps roles are such only if the "Dev" and "Ops" parts are connected--I.e., you manage operations for the software that you've developed. I agree that there are rapidly diminishing or negative returns otherwise. E.g., if you write some Nodejs web services on Monday and troubleshoot MS Exchange/ActiveDirectory integration issues on Tuesday, there isn't much benefit. In that case, however, I'd argue that you don't have a DevOps role, you just have 2 different unrelated roles (which, as I stated, is apparently a definition issue on my part).

The only part that I would argue with is..

The difference is between developers knowing the operations side and being the operations side.

You cannot, in my opinion, "know" the operations side if you have never actually been the operations side. The real question is whether knowing the operations side is worth the effort of being the operations side (at least for a while). In my experience, the answer is unequivocally "yes" (but again, with the caveat that you are the operations side only for the software that you develop, and not for, e.g., rolling out the latest Windows service pack to all users at your location).

I should also clarify that my experience has only been with internal development. The demographic differences with respect to external-facing applications (i.e., user/developer ratios on the order of possibly millions to 1 vs. 10s or 100s to 1), among other things, would necessarily limit the ability of developers to participate in operations.

As you've noted, having to run operations to the exclusion of all development activity would bore you to tears. What that has done is forced me to consider--to a degree and precision that would never have occurred to me previously--how the design and architecture of a proposed solution impacts deployment and operations. Because I did not want to spend all my time supporting the system I mentioned in my previous post, I designed it such that it required about all of 30 minutes every other month to administer, and was easy as hell to troubleshoot in production. This meant a much more complex design, and more difficulty in implementation, but saved me a ton of time on net balance such that I could still spend the vast majority of my time doing more interesting stuff.

If deploying and administering the software that you've developed becomes your full-time occupation to the exclusion of all other activity, then either:

  1. You do not actually understand deployment and administration in the relevant environment(s), and are therefore horribly inefficient at it (and would benefit greatly from learning).
  2. Your design made it very difficult/time-consuming to deploy and/or administer. This is almost an inevitable outcome if the above is true, but can also occur if the developer has a "not my job/problem" attitude when it comes to deployment and administration, or can be a straight-up deliberate trade-off based on available resources.
  3. Both of the above. Or...
  4. You are working at a scale or in a domain for which deployment and administration is an inherently difficult problem independent of solution design (though paradoxically in this case it is usually even more important for the developer to understand Ops, because while there may be little they can do to make the hard problem easier, there are lots of ways they can inadvertently make the hard problem impossible).

DevOps (1, Insightful)

ShaunC (203807) | about 6 months ago | (#46763701)

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.

"Developer is at the top" oh please (0)

Anonymous Coward | about 6 months ago | (#46763717)

If your latest vaporware won't scale, no position matters, if your code won't run no position matters, if your code is so full of bugs it drives people away, no position matters, if it doesn't do what users want no position matters. If all you want to do is be a developer, then get a job being just a developer.

This is dumb (0)

Anonymous Coward | about 6 months ago | (#46763725)

I've seen DevOps work quite well in a large technology company (thousands of developers) - it's actually all about empowering developers to get stuff done rather than to build their software and then wait 3 weeks for the virtualization team to build them a VM, and another 2 weeks for the network folks to get around to open up ports in the firewall, etc. It's an outgrowth of the fact that system administration tasks are being automated to such a degree that, for day to day stuff, you can actually take sysadmins out of the picture - maybe you still need someone to approve things from a policy standpoint, but there's no reason to have to wait around for someone to manually configure and deploy something for you when so much can be automated with tools like Chef or Puppet.

What type of Operation (0)

Anonymous Coward | about 6 months ago | (#46763731)

If you work in a software development shop then the Operations department IS software development. If, on the other hand, you write software for a plumbing company, yeah it makes since that you shouldn't be plumbing.

I actually did RTFA and the supposition that flexing cross functional development skills is a bad thing is not correct.

Please... (1)

Wolvez (13077) | about 6 months ago | (#46763737)

This smells like yet another attempt for a prima donna developer to avoid responsibility for the havoc his or her shoddy code wreaks upon the real world. Sad.

Re:Please... (1)

BradMajors (995624) | about 6 months ago | (#46763835)

Exactly. Most developers are incapable of producing code that anyone would ever want to use.

In multiple companies for which I have worked, it was known who was capable of producing code that could actually be shipped and who could not. Management highly valued those who were capable of producing shippable problem free code.

devops == just get it running (IMO) (1)

jopsen (885607) | about 6 months ago | (#46763745)

That's what I do... Just get it runnning... then later, someone can fix it... Or not... And it can run until it crashes and burns...

Unless, you're doing something really important "running it right" is often overkill :)

It's all about timeframes... (3, Informative)

QuietLagoon (813062) | about 6 months ago | (#46763823)

.
Operations people work in a timeframe of minutes to days

Developers work in a timeframe of weeks to months

Researchers work in a timeframe of years to decades

When you take a developer, who thinks in terms of months, and task that person to think in terms of minutes and hours, you are wasting a resource.

When you make someone respond to an overly wide range of timeframe-based events, the short term events always crowd out the longer term events.

Have you ever noticed that companies locate their research divisions away from the day-to-day operations divisions? It is to keep the timeframes separate.

Re:It's all about timeframes... (1)

Antique Geekmeister (740220) | about 6 months ago | (#46764007)

> Have you ever noticed that companies locate their research divisions away from the day-to-day operations divisions? It is to keep the timeframes separate.

No, it's turf building and budget protection. By segregating the developers from devops, devops can _hide_ their resources and keep them sequestered from developer requests. And putting the systems into a "requests go to managers, and only then to devops" makes the managers vital to allocating resources. It can protect their team from excess pecuniary demands, but far too often it's used to make the manager more important to the process than they should be, and grants them personal power over other groups' projects.

I've been documenting a tragic example of this for the past few weeks. I'm afraid the manager is in for a _big_ surprise when they find out that writing run books is their new highest priority, and their personal approval of run books is no longer expected.

python guru-pth! (0)

Anonymous Coward | about 6 months ago | (#46763865)

So if this douche is a python guru, that shows just how much the guru know about the enterprise and how SDLC works in reality.

The level of separation that said python guru is familiar with is mostly a product of Sarbanes–Oxley.

However before SOX this level of separation was very common in mainframe shops, where frequently developers weren't even allowed to compile their own SQL. That was the DBA's job.

In start-ups, even before the great internet revolution developers frequently performed all roles, Hardware, Admin, DBA, and Dev.

I think the guru needs to get more experience out of the python box.

Cry more, cupcake... (1)

Rick in China (2934527) | about 6 months ago | (#46763867)

In SO MANY cases, especially in big companies as the OP has alluded to, there is a huge bottleneck in communication between developer and operations - resulting in submitting tickets, waiting in queues, eventually getting operations-related work done so they can unblock their development progress. Solution? Give them the power to make changes themselves. Result? DevOps. OP is just a whiner because he doesn't like what so many demand. Great. Many companies don't even know what devops is, let alone strive to implement it - join one and shut up, nobody gives a shit if you don't like how your organisation is changing your position to one where your existing role is sent to an offsite backup warehouse to die.

Re:Cry more, cupcake... (1)

Todd Knarr (15451) | about 6 months ago | (#46763971)

That, though, is talking about the development environment itself. Yes, there the developers should be in control of the machines. DevOps, though, is about having developers actually doing operations tasks in the production environment. That's a bad thing, because what developers are good at is very very bad in production. You don't want developers alpha-testing code and fixes where a failed test brings all of your customers to a screeching halt while the developer does a few more iterations to get his fix working right. Plus, frankly most of Operations is boring and tedious (or at least it should be) and as a developer I have little or no interest in making it my day job. I want to solve the problem of making the deployment scripts bulletproof and go on to the next problem, not spend my day watching instances spin down and up (because if I did my job right, that's all the Ops people are going to need to do).

Analyst/Programmers ... (1)

Kittenman (971447) | about 6 months ago | (#46763923)

Anyone else remember a day when this function was split? Back in the early days, we had Systems Analysts, kept in a separate room to the programmers.

DevOps,,. we've seen this sort of thing before. End result is that we get less specialists, and things become harder to fix when they break. But, multi-skilled people are the way things are going. And have been since ... well, Michaelangelo was a sculptor who was asked to paint. And I have some of his sonnets, somewhere.

Re:Analyst/Programmers ... (0)

Anonymous Coward | about 6 months ago | (#46763975)

Splitting Analysts and Programmers into separate jobs is useful. Having a dedicated Ops position (the guy that turns the servers on) is not. Sure you can end up in a clusterfuck situation where you systems become so insanely idiotic that it takes a specialist to make them work, but that is not a very good outcome.

DevOps is about designing your systems so that the developer can just click and deploy the work they've created. If that means less operator jobs then cry me a river.

Re:Analyst/Programmers ... (2)

BlazingATrail (3112385) | about 6 months ago | (#46763989)

you used to carry your stack of punch cards to a Demi-priest, who passed them to the Priest who was the only one that was allowed to touch the computer. Funny, how even today that role still exists.. it's called a DBA.. these jerks won't let mortal developers near a database, even though the dev writes the script to be run against production, and DBA monkey just hits Run for you.

horseshit (1)

whistl (234824) | about 6 months ago | (#46763953)

Developers too often seem to think they know everything, when (esp on large teams) often they have zero idea what it takes to bring their ideas to the real world. It takes serious designers to develop a scalable app, even if lots of people think they know how. I work in production support of multiple websites, meaning I have to clean up after the mistakes developers make on a daily basis. The support folks who have to write patches for our products often grieve over the situations the original developer placed them in. It often takes a major rewrite to fix many performance issues, because the original programmer never imagined all the different situations their code would be used. Prod support is where the real issues are discovered and solved. Accept it and move on.

The Disney Way (1)

BlazingATrail (3112385) | about 6 months ago | (#46763969)

Read the book The Disney Way.. it doesn't matter if you are the CEO or there to paint the fence. If you see garbage, you pick it up. It's about everyone pitching in to make a company awesome. (said in a Disney Princess voice)... but seriously... Of course everything is a balance, I think the operative word is "occasional" ops.. it doesn't take much time out of dev schedule to manage a web server or VM so your product just keeps working, especially when it is a new product and the production ops are still being figured out.

DevManPwn is better. (1)

RandomStr (2116782) | about 6 months ago | (#46764073)

The permutation of so-called devops that works best for me (and successful start-ups IMHO) is where the developers are also management(being the owner is the cherry on top), of course it only really works in a software company...

You'd be amazed at how much more accountable(function) non-devops managers are when they know then can't pass the buck the developers(threaten outsourcing, etc.). Think Bill, Woz, Sergey & Larry etc...

Devops is not killing the developer (1)

kimvette (919543) | about 6 months ago | (#46764095)

Devops is not killing off developers. What it is doing is combining the jobs of a traditional Release Engineer and a traditional Linux System Administrator. It's right up my alley, actually, so I am looking to move on for exactly such a position.

DevOps (0)

Anonymous Coward | about 6 months ago | (#46764143)

Just another buzzword of the day. When I first came across this term it was described as a tighter collaboration between development and operations instead of the build it and let someone else worry about getting it into production.

Primarily Ops (1)

_dougster (3617965) | about 6 months ago | (#46764193)

What I have seen when interviewing at tech startups in the bay area (and I've interviewed with a lot) is that devops roles are primarily operations roles, with an added emphasis on working with developers to get code out quickly. Simple as that. Companies still expect the devops guys to do all the sysadminy stuff, and respond to alerts and put out fires.

tautology (1)

Mozai (3547) | about 6 months ago | (#46764281)

"Somewhere along the way, however, we tricked ourselves into thinking..."

So: when a good idea is implemented poorly, then bad things happen. Why is this news?

'DevOps' isn't killing the developer; people who are abusing developers are killing developers and using [place idea here] as an excuse. If you focus on 'DevOps', then you're going to throw out an idea and do nothing to prevent people abusing developers and using [idea n+1] as an excuse.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?