Diff: DevOpsMeansDontBeAnAhole

Differences between version 2 and previous revision of DevOpsMeansDontBeAnAhole.

Other diffs: Previous Major Revision, Previous Author

version 2

DevOps Means Don't Be an A-hole

"If the company's doing well and people don't hate each other, you're probably doing ok."

– John Allspaw, speaking at Devopsdays 2011 MV.

This year I had the pleasure of being a panelist at Devopsdays 2011. This is a two day mini conference where people interested in the DevOps movement get together to discuss the state of our world. The general topic of the conference was the technical and philosophical questions involved in building, deploying, and managing complex software systems.

I come to the world of DevOps from the operations side, as I've written about before. I currently work at Yahoo on very large software installations and I am keenly interested in whether DevOps can result in more efficient practices and happier people. These days I'm cautiously optimistic about DevOps, but for reasons that somewhat surprise me as I'll outline below.

The above quote was just a casual remark from John Allspaw as he moderated one of the Devopsdays panels, but it really got me thinking. One big concern I've had with DevOps is the over-emphasis on tools and programming. Like any technical person, I'm always looking for a better tool to solve my problems. In my case that seems to lead to writing more and more complex perl scripts, and playing around with things like Test Driven Development and sprint planning.

Those are good tools, but you can't define a movement by the tools it uses. Movements are about philosophy and group consensus.

When John made that comment, it crystallized something for me: DevOps isn't about tools, it's about people getting along. The problem with our existing development vs. operations divide is that people don't get along. For various perfectly good reasons, the traditional software development and deployment paradigm results in distrust and fear, on both sides of the fence. Development create change, Operations is penalized for change leading to outages, etc, etc.

So, what's the alternative to devs and ops being at loggerheads? Communication. As John said, it's about people not hating each other. That hate comes from fear. We all deserve to work in an environment of mutual respect, and the only way to get to that is to overcome our anger and talk to each other.

Almost all the roadblocks in my own career have been due to communication failures. Many (heck, most) of those failures were probably my fault. Here's a couple of real recent examples:

1. I attended a meeting with a (different) development team to discuss the design of their software. They want to design their component to protect their servers from misconfiguration at all cost. The problem is the way they do this leads to extended software install times. My Release Management team pushes this software to tens of thousands of production servers, so a 15 minute delay on every host has some pretty serious consequences. In the meeting, I tell the development lead that they are doing things wrong. Tempers flare and everyone in the room gets pretty tense during a heated 'discussion'.
2. My operations team has been working with a very difficult development team. The developers don't seem to know what they are doing, and it feels like the project manager isn't on top of the schedule. This leads to a lot of internal grumbling in my team about how this other team is a bunch of idiots. On a team conference call, I spend some time complaining about how that development team has yet again missed an important deadline and caused our team to have to work harder.

What do these two examples have in common? In both cases, I failed to communicate properly. Let's look at the first case: what was the benefit of how I handled that interaction? Almost nothing. Maybe I felt a little better after I told the developers they were wrong, but that's not going to

My manager pointed out this can have some far-reaching effects. I'm a senior member of the team, so my opinions for good or bad carry a lot of weight with my team members. This is a situation that most people in the devops world are probably in - many of use are more senior developers and sysadmins.

After I thought a bit more about this, I realized my boss was completely right. Negative talk is poisonous, especially when it comes from senior team members. Think about it: my negativity about the problematic development group sends a clear message to the rest of the group that I think that other team is a bunch of goddamn idiots. That's a lesson that everyone else on the team is going to consciously or unconsciously emulate.