DevOps and the blame problem: an outsider's view
September 26, 2011
I'm an outsider on the whole DevOps movement (we don't have anything like a traditional operations or development environment here), but from my outside perspective it looks like DevOps is really an attempt to deal with the blame problem.
The traditional organization's approach is to blame operations when services aren't running (or aren't running well enough) and to blame development when features aren't delivered. When you blame devs for not delivering features, well, your devs deliver features but not necessarily things like stability and performance. Since ops is not stupid, it then does its best to refuse to install or change things from development, or even let them near what it'll get blamed for.
(Even if ops is either stupid or optimistic, it does not take very many rounds of 'do thing for devs, world explodes, get yelled at' for the negative conditioning to sink in.)
You can tell development that stability, performance, installability and so on are important too. But it doesn't help; when you blamed devs for not delivering features, you told them what their first and foremost priority was and you're going to get exactly what you asked for. Equally, you can tell ops that being responsive to development is important (either directly or by invoking the good of the whole business) but when you blamed them for services dying you told them what their big priority was. This is not surprising in the least; people are very good and very motived at not getting yelled at.
(Some people think that they can fix the ops side of the problem by blaming ops both if services go down and if development updates aren't deployed promptly. This is a great way to lose anyone in ops who's smart enough to realize that they've been given all of the responsibility and none of the power. Or to put it the other way: people who get yelled at all the time quit.)
At its best, DevOps transforms this to 'devops gets blamed when features aren't there and reliable on the site', joining together both things that you actually want. At its worst, DevOps at least gives the sucker with all of the responsibility some power as well.
(See also Ted Dziuba.)
Sidebar: why ops gets the short end of the traditional stick
Developers at least have the chance of exceeding expectations and thus earning praise; they can deliver features really fast or they can deliver really impressive features, work beyond what people expected was reasonably possible. And anyone can be impressed by a well executed feature because it's generally quite visible.
Ops, well, how does ops exceed expectations? Ops are like janitors; we assume that clean buildings and working services are the natural state of things. You don't get points for either. It's just your job. But miss a spot and boy, the blame rolls in.
(Ops gets praise in exactly the situations where people understand that something exceptional is going on, which generally requires a disaster. Unfortunately this breeds a tendency towards 'heroism'.)
Written on 26 September 2011.
* * *
Atom feeds are available; see the bottom of most pages.