There are some great posts out there on the superlative DevOpsDays London 2016 Conference. Of particular note are Manual Pais, DevOpsGuys and Helen Beal’s DevOpsDays London: Making Happy. These are well structured, balanced pieces which neatly represent each talk along with insight from experienced authors. I hate to disappoint, but this post is not one of those. It’s a random collection of the things that peaked my interest at DevOps Days London.
What is Legacy?
There was lots of talk of legacy, the BiModal debate rolled on. Much like the sporadic agile wars many of the detractors use out dated definitions as convenient ammunition, Gartner’s understanding of the challenges seems to have evolved away from its original strategy towards an exploit and explore approach for recent and legacy systems respectively. Defining legacy is challenging, with considerations beyond just the age of the software or system. There were a few definitions I really liked:
“Legacy is code you can’t iterate on as quickly as you need to” – Casey West
“Legacy is code you don’t have automated tests for. – Micheal Feathers
“Legacy is where your customer money lives” – Bridget Kromhout
The merits of really reading
I keep having the same conversation, like being in a endless loop, it goes like this:
Person: “Yeah, I know all about Conway’s law, it is super insightful”
Me: “Exactly, that example about teams building compilers, that’s a light bulb moment”
Person: “….the compilers?”
Me: (Thinks) “Have you really taken time to understand what you’re advising people to do, or are you just reciting tweets?”
Me: (Says) “ Check out the article, there’s lots more in it”
It is like this with so many topics, REST, OODA, Learning. That’s why I was so pleased to hear the ever-eloquent Gareth Rushgrove call out the value of reading academic papers in his talk. These days we are so prone to snacking on sound bites we seldom get the satisfaction of a full reading meal, yet our brains cry out for this kind of nourishment. I believe papers, and source material in general, are the best way to gain a firm understanding of a topic, particularly because they build a picture of what motivated the author, not just what they did. Much like software patterns, understanding the intent and motivation is key to successful application.
A couple of talks touched on burnout, as did a well attended and lively open space. What surprised me was how many people had direct experience of it, it remains an issue in the industry despite raised awareness and talk of sustainable, humane ways of working. Oliver Wood talked about his experiences working so many hours that he slipped a disk. Keen that others may avoid the same fate, he created GoodCoderBadPosture. During his ignite he reminded us “you are ephemeral , you are not highly available“. My talk (Things I learnt About DevOps When My Car Caught Fire) used the analogy of looking through the windscreen of my burnt out car, all the instruments you normally rely upon to sense the world are warped and confused, your view is fogged and distorted. If only we could see metal strain as readily as we can bad posture.
I noticed much of the burnout open space was concerned with what management and organisations can do prevent burnout, and recognise it’s occurrence. This is a reasonable standpoint given that our behaviours are generally shaped by the systems we work within. However In the spirit of DevOps we should also note that it isn’t a problem for effected individuals and their mangers to tackle alone. While organisations take action, we might also ask ourselves:
1. “How would I know if one of my colleagues was suffering from burnout?”
2. “How would I help someone I thought on the verge of burnout?”
3. “How do my own behaviours effect the likelihood of burnout in my colleagues?”
There was a nice note in Jeromy Carriere’s talk, and a potential answer to question 3: “Work hard to make every alert exciting” this has implications for burnout, exciting alerts implies only being disturbed for hard problems, not simple switch flicking exercises.
There was plenty of talk of change, particularly the danger of not evolving and experimenting. Change strategies were discussed, including the value of heading into conversations well armed with data. It was clear from their talk that Microsoft are changing in places, for instance setting up open team rooms or neighborhoods. I rate this approach, it appears to balance team privacy, open communications and the distractions of full open plan.
“It is not necessary to change, survival is not mandatory” – Deming (Who wasn’t present!)
“The riskiest thing is not to change” – Joanne Molesky
The change theme included the importance of investing time in the most valuable activities, and how to discover them. It highlighted that many of those valuable activities are operational features, not just shiny new toys to please users. If you’re in the mood for self reflection you might give some thought to this quote from Bridget Kromhout:
“When evaluating yourself don’t forget to look at the value you are adding”
A conference, with a culture
The thing I love about DevOpsDays, and the way it’s organised, is that it still feels like a community event, sure it’s scaled, but the level of friendliness, inclusion and support are almost as the first time I spoke in Goteborg 2011. The story of this scaling and principles behind it were told by Kris Buytaert, it’s surprising how many of the early adopters are still active. The conference manages to short circuit a lot of anchoring and group think by giving almost 50% of the time to open spaces. Taking responsibility for the schedule out of the committee’s hands into the delegate’s ensures that topics are relevant to attendees, right then and there. The willingness of speakers to stay and participate in these sessions is key to their success and makes for some great learning. Not bad for a movement that still can’t agree what its about.