Partitions and Warfare

Official U.S. Navy Imagery

This is a guest post by Julian Simpson. Julian blogs about builds, continuous integration and deployment at The Build Doctor by night. By day, he works in London as a build manager and systems administrator. Previously, Julian did a four year tour of duty at ThoughtWorks who plucked him from a systems administration role. He has worked in the IT industry since 1991. Don’t bring up his age in conversation.

“You butt-head developers!”

“You pedantic sysadmins!”

Developers and Operations teams are frequently at war. I have seen such trench warfare as a systems administrator and as someone on the dev team. It’s a conflict that happens each day in businesses all around the planet. What’s the root cause?

Some conflict is necessary to foster creativity and challenge the status quo. Too much becomes destructive. Why does it get out of hand? I’ve got three reasons for you:

• Misunderstanding
• Conflicting organisational goals
• Group memberships

Misunderstanding is perhaps the biggest issue that I have seen. Developers aren’t trained in operational concerns. Sysadmins don’t often understand what impacts developer productivity. When a developer works on a feature to find out that his approach isn’t acceptable in operational terms (like the guy who tried to make outbound HTTP sessions from the middle tier of an n-tier system), he’s understandably going to be miffed. When a sysadmin finds out that a system has been signed off but is operationally incomplete, he’s not going to be happy either. The solution to this is communication. Lots of it. I suggest lunch.

One of the most damaging issues is that development teams and operational teams often have conflicting goals. Developers get rewarded on delivering quickly. Operational teams get a good rep if they keep services running within agreed SLA’s. That’s never going to lead to harmony. Unfortunately, we seem to keep building organisations which separate writing code and running code into different buckets. In some cases, there’s a governance-driven reason why you need to do this. If so, there’s probably money or lives at stake; fair enough. But, in other cases there’s no reason why developers can’t get more involved in deployment. The more of your own dogfood that you eat, the better you want it to taste. By the same token, I’d cheerfully make some systems administrators sit in a developer’s chair and try doing their job for an afternoon.

Most interestingly, the fact that you’re in a group changes your perception of those around you – unless you’re Groucho Marx. Members of a group will identify with that group and exhibit a bias towards the group’s needs above that of the organisation that sponsors it. One’s own cognitive biases can be the hardest to spot!

So do me a favour: next time you encounter your adversaries, think about your reactions to them. Is it really just one of you that is wrong? Or is there something more complex, and perhaps more interesting, going on?