Code Freeze 2012 Continuous Delivery - II

Presentation number two of Code Freeze 2012 was Michael Nygard who spoke on "Dev Ops Cooperation at the Worst of Times" or, as he called it, "When the fur flies." Michael is the author of Release It! by the Pragmatic Programming group, in case you're familiar with the book. His presentation was less "how to" and more "what  happened."  Anecdotes about a situation he was in where (product) life when horribly wrong, how it went wrong, and what they did to compensate.  And subsequently what the efforts to make it right meant to company culture (a focus on heroics and looking for the next hero).  It was a good talk because, if you work for a large company, it seems very few people talk about the bad stories at work.  Why? Because the people involved in the bad stories and the bad decisions are still there and possibly in executive management and they don't want to be reminded that something went wrong and cost millions of dollars.

To summarize Nygard, I state what so many people have said before, small teams often work much better than large teams.  And although he spoke to the connection between Dev and Ops and the collocation of both, to me the real point is that no project stands on any one team alone, and the more you understand the stack and the role of others and work with them to identify the connection points, the more success you'll have.  As he said, organizational boundaries can become process boundaries and while it might seem like that's the sign of a organizational maturity, it is anything but.

Nygard had quite a bit of advice on the interaction of Dev and Ops (and other teams).  He reiterated there is no "they" and there should be no stereotypes such as "ops is crabby."  And the reverse is true, Ops shouldn't complain about "my poor system" and try to shield it from the "hordes of developers" intent upon subverting it by talking about putting developers in jail with no sudo rights.  Some software solutions rely on hardware solutions.  Some hardware issues can only be resolved by working with the developers and understanding what the conditions the software was architected under.

Nygard listed four traits he feels are necessary for effective DevOps:

• Culture
• Automation
• Measurement 
• Sharing

He also listed the types of folks he prefers to avoid.  Among them are "function point project managers", a term I hadn't heard before.  It refers to project managers who see the date as the overriding rule for a project to which all things should take a back seat.

And he mentioned the attrition rate for developers (coders) is very high in the first three years, and 50% by year 10.  I'd be interested to know where he got that statistic.  I'm obviously an example, as I moved into system training (with some development) by year 9 (at my current employer, if you include contact time), and management by year 11.  But I haven't given any thought to whether that holds true across most folks I know.  Ming obviously.  Erik not (in my opinion.  He still codes).  Mean Mr. Mustard not.  But then again, that's 50%.

The one thing I found humorous about his presentation, rather than his general humor, including a Magic The Gathering card of The Machine That Goes Ping, was his diagram of the usual dev ops interaction.  I've recreated it as best I can from memory below.  I find it ironic that on the U of MN campus, someone is diagramming Dev Ops interaction as a glory hole.  If you're not familiar with the term, look it up.  Just not at work.