This year was my first year attending ChefConf.
For episode 19 of The Ship Show, we did a joint podcast with the Food Fight Show Crew, and had a ton of fun; if you’re looking for a high level review of the conference, that’s a good place to get a high level overview1.
Even though it wound down over a week ago, it cracked open a world view that I’ve not had a lot of experience with to date, and that experience was pretty impactful, so I wanted to discuss it a bit more after having digested things.
It’s interesting to me that most of the people attending ChefConf are approaching many of the same topics we do in traditional “release engineering” for “native”/”boxed” software, but it’s similarly patently obvious that the dynamics and interactions2 can be pretty different too.
To whit: I found it very interesting that among a sea of developers in talks and in the hallways, I could pick out common themes that wouldn’t surprise any practitioner: version control, deployment, scaling, configuration management… but one phrase I did not hear uttered once by a single person was “release engineering.”
What is especially interesting was having heard bits of pieces of various conversations, it’s clear that the problem space people were tackling had a great deal over overlap with the issues release engineering has been tackling for years.
It’s just no one called it that.
I haven’t quite been able to figure out why that is.
It’s possible that “release engineering” may have a “curmudgeony” connotation to it, so there’s a desire to distance from (any) roles that have traditionally been at odds with “lean manufacturing”3 concepts. Or, perhaps, it’s just that the bulk of the attendees at ChefConf hail from a so-called “[Web]Ops” background, and release engineering (and release engineers) weren’t an obvious part of the Web 1.0+-world?
I don’t know… but no matter your opinion of release engineering, all y’alls are doing it5… even if you don’t know it, or find the concept abhorrent.
Which brings me to the next thing I found fascinating: we did a word association segment for The Ship Show with various conference-goers that turned out not only be a lot of fun, but revealed the wide, often extremely disparate viewpoints on some standard ideas within the DevOps sphere. For instance:
- “Release engineering” prompted responses spanning from “confusing”, “tiring”, and “hopefully a thing of the past” to “sanity”, “frictionless”, “really cool”, and “craft.”
- “Configuration management” prompted “hard” and “Jeezum… yah… no… I dunno” all the way to “good”, “sanity”, and “important”7.
- “Shell scripts” engendered, on the one hand “old school”, “horrifying”, “obsolete”, “the fallback”, and “if you have to” all the way to “kinda awesome sometimes”, “I like ‘em”, “much needed”, and “actually pretty awesome.”
- Our beloved “DevOps” excited utterances ranging from “I don’t know”, “ouch”, “dear God”, “confusion”, and “not-a-Thing” to “sweet”, “cool”, “so cool”, and “fun.”
You can draw your own conclusions8, but as someone who spends his days thinking about DevOps, the people who identify as part of that community, and the problems it faces, I found this illustrates the group’s real heterogeneity.
In attempting to fix broken social and technical systems, I think we can often forget or gloss over the fact that we’re, and the systems we work on, aren’t as uniform as we might think, which is probably something we should all be more aware of.