ok ok i have one more thing to gripe about^W^Wcommentate today: the @overopshq devops accountability survey results.
it's a super fun read, and i applaud the trend of doing community research and making it look pretty. check it out: resources.overops.com/wp-content/upl…
it's a super fun read, and i applaud the trend of doing community research and making it look pretty. check it out: resources.overops.com/wp-content/upl…
i like that the responders are a nice broad cross section of roles, representing IT and testing as well as ops and dev. i wish you could break down by IC and management roles as well. (actually i REALLY wish it was an interactive result set you could play with, but ah well.) 
Here you lost me. Fully devops? Partially devops? No plans to adopt devops? What is devops in this context? How can one be forty-two percent devops? I am so beyond lost here. They don't clear this up at all, we just move on to the next thing.
93.2% are deploying at least once a month -- well, that's good i suppose
43.8% of respondents align their code or feature releases with sprints -- this feels like an anti-pattern to me, tho goes unremarked upon. why not ship continuously?
43.8% of respondents align their code or feature releases with sprints -- this feels like an anti-pattern to me, tho goes unremarked upon. why not ship continuously?
still thinking about that deploying once a month thing. 🤔 what i actually want to know is the interval between writing the code and running it in production. didn't the DORA report have something about that? (note to self, look up later)
44.6% that have fully adopted devops (again, whuh?) say moving too quickly results in prod errors -- feels like wobbly science. what moves too quickly? why do they think this? only 38% of all respondents say moving too quickly causes probs, leaving me with even more questions.
i would like to see some definitions here, or the original wording of the question, because otherwise this sounds like only 62.7% of respondents monitor their services and 63.2% use automated testing. that seems farfetched.
this graph seems basically meaningless. 41.0% say they use manual & automated processes ... the other 59% are lying or don't know.
and i'm gonna stand up for the folks who reported that they rely on customers to find issues, because LITERALLY EVERYBODY DOES. Everybody.
and i'm gonna stand up for the folks who reported that they rely on customers to find issues, because LITERALLY EVERYBODY DOES. Everybody.
Look, there's no shame in your customers having to tell you about errors and problems. Save your pearls for later clutching.
The shame is only if they have to tell you about the same problem, repeatedly. That's not ok.
The shame is only if they have to tell you about the same problem, repeatedly. That's not ok.
Lastly, I want to pick on the part about accountability, because I think they get it wrong -- and the respondents mostly get it right.
Who is responsible for quality of code and services? *Everyone* is. That is correct, your headline is wrong.
Who is responsible for quality of code and services? *Everyone* is. That is correct, your headline is wrong.
(this gets my vote for most puzzling and meaningless graph of the whole thing, reflecting the fact that literally nobody knows what "devops" means):
The difference in these responses come from people interpreting the question differently.
Who is primarily responsible for code quality? developers. Who is primarily responsible for operability? operations. There, I fixed it.
Who is primarily responsible for code quality? developers. Who is primarily responsible for operability? operations. There, I fixed it.
There, that's all I'm going to pick on for now. Dear @overopshq -- next year, I would love it if you replaced the confusing bits about ownership and responsibility with questions that show how total software lifecycle ownership leads to improved SLO outcomes. Thank you!
