[agentultra]

I argue that the shared responsibility mentality is distracting and diminishes the power of an individual. It's hard enough being a good programmer let alone one that also knows how to configure networks, firewalls, and operating systems; one who knows how to manage security policies, LDAP organization charts and ACLs, etc. I still believe that the jack-of-all-trades is a useful individual but I don't believe an entire organization should be formed around their ideals.

As in all things in life -- the truth is somewhere in the middle. If you build significantly sophisticated systems you will need specialists at some point. I don't recommend wasting their talents on getting reamed out for forgetting to configure the firewall properly.

[mfisher87]

I don't think that's what the author is arguing for. More like, "You build it, you run it" (quote via article). Instead of handing your code off to someone else to be 100% responsible for testing, for release, for production support, the author argues that it is better to have developers share responsibility in those roles. It's very similar to what I'm doing now.

We don't hand off code to be installed, we give a release plan, an installation plan, and the code. We are on call for first runs, and there's always a subject matter expert developer on call to support overnight issues if the support team needs help. If you have this responsibility, you write more responsible code. If I may support something overnight, I'm not going to unthoughtfully make it hard to support. We share testing and documentation responsibility as well (although documentation is an issue), so again testers and support are doing their job in a vacuum because they don't have the developer's insight to the program. In fact, devs do most of the testing. It's not always easy to write test cases for a system you didn't write or design. I've kind of always thought that it's common sense to support your own product in test/production as needed (though not the first point of contact). You wrote it, you're the expert.

Reading this article surprised me because I thought it was the same everywhere. Having no responsibility for testing or prod seems like asking for bad code. If you're just writing code, you're not going to focus on what it's going to be like to support it, install it, maintain it. You'll have other, more concrete (to you) things to focus on. Coding standards may become more important. But are standards really as effective if they're not informed by / don't care about responsibility for a production product?

[agentultra]

Perhaps it's that funny definition of "devops" blurring the lines.

I think it's perfectly reasonable for a developer to be aware of excessive memory fragmentation, leaking FD's, and anything else related to the process their program directs. It's well within my domain to debug such issues.

However the "devops" role is also pushing responsibility for configuring firewalls, LDAP ACLs, securing the OS, managing init daemons, and the entirety of the infrastructure on developers. Since it's all code now there can be more people involved and the silos can come down. "You build it, you run it," as you say.

What I'm suggesting is that for significantly sophisticated applications it won't be tenable to spread the responsibility on everyone. It's not reasonable to suggest that everyone be familiar with the implementation of a simulated-annealing algorithm in the continuous-domain constraint search solver. I think a support person would be well within reason to defer questions, bugs, and requests with that particular part to the developer responsible for it. And yet we're arguing that it's perfectly acceptable for that developer to be familiar with the intricacies of managing a data center of compute clusters? I don't know about you but I don't have an infinite amount of time on this Earth to take on such responsibilities.

I do think that there's a middle-ground to be exploited. If our expert system is ballooning in memory usage and crashing our servers it's reasonable for the developer to profile the memory usage under simulated loads and data sets and look for memory fragmentation or leaks, etc. I think it's a little too much to ask one person to also be intimately familiar with managing compute clusters, RAID failures, security policies, and package management. They, like many of us, may have a good, general idea of how it works but there exist specialists for a reason: it's hard to go beyond a certain degree of complexity without focusing. It's the reason why we work in teams!

[mfisher87]

>It's not reasonable to suggest that everyone be familiar with the implementation of a simulated-annealing algorithm in the continuous-domain constraint search solver. [...] we're arguing that it's perfectly acceptable for that developer to be familiar with the intricacies of managing a data center of compute clusters? I don't know about you but I don't have an infinite amount of time on this Earth to take on such responsibilities.

No one is arguing for that, as I said. Where in the article do you see something like that? No mention of firewalls, data centers, developers doing their own server administration. This seems to be a more important takeaway from the article:

> Ultimately, DevOps is about empathy, with everyone on your team and with your customers.

No one is suggesting "everyone does everything" at all... you're sort of creating an argument here.

[mattgreenrocks]

Another way to look at this is that this yet another bog-standard business magazine article telling you should be working harder, longer, and appearing more dedicated than your peers to better differentiate yourself in this "fast-changing" world of ours.

[eweise]

I agree. Devops is just management speak for doing two jobs on one salary. Plus they find it hard to convince ops guys to wake up every night responding to alarms so calling everyone devops they can spread that pain among more people.