The Rise of BlahOps


Last week, Perforce’s Matt Attaway and I got into an interesting twitversation de-constructing our beloved “DevOps” word.

It all started because I received an email from a recruiter with a job description referencing a “DevOps team”1, but with a description2 that sounded eerily familiar to the bread and butter of a build/release team.

Matt suggested I start a “BuildOps” movement, where I “Take all the existing text on build; s/build/BuildOps; profit!” Despite lamenting the overuse of the term “$blahOps,” the sad part is: he’s probably totally right; there probably is a mint to be made with some awk‘ing there.

What I thought most interesting, though, was his last observation on the matter:

We’re stuck with $blahOps I think. Movies have trained us to think ‘BlackOps’ are cool; anything + Ops sounds more awesome.

I’d never thought of it that way, but I think he’s onto something there. The imagery of Army-green helicopters, with soldiers jumping out of them, yelling “Go, go, go!” is not far in our imaginations whenever the word “ops” is uttered.

The irony of it all is that as many organizations try to transform themselves to the new, improved “DevOps” versions of themselves, they still ignore or under-invest in operationalizing their teams and their infrastructure. Myriad examples abound in anonymous, complain-y tweets: the CI server under the desk (or “in the cloooouuuud!” paid for with one developer’s personal credit card account3), the “just throw all the bits on S3, it’s fine” “artifact-management strategy”, the continuously muddled communication about who is responsible for which tasks, the shoving others aside justified as “just gotta get my job done”4, the indictment of the mere notion of repeatable process or consistency across actors5, the withstanding people not in right roles6. These are all antithetical behaviors of these “[Black]Ops” teams we so idolize. And yet, we think if we tack Ops on, some of that magic will imbue itself to our endeavors.

Of course, the part those movies often gloss over is the many hours7 these teams spend training and getting to know and trust each other, and how much stock they put in process (and yes, even Process) for the simple things, precisely so they can save their energy, mental and otherwise, for the complex and unexpected.

The lesson, illustrated once again is: just adding “Ops,” Dev- or any other kind, to your organization isn’t going to solve problems, business or otherwise… even if it does sound cool8.

  1. Strike one
  2. “… an opportunity for a Sr Build/Release Engineer to join a DevOps team responsible for Build, Release software packages [sic] as well as deploying to different Cloud [sic] environments.”
  3. They’ll never leave the company, obvs
  4. Instead of working with and trusting them
  5. “Because, dammit, I have thoughts and feels on Python formatting AND THEY’RE IMPORTANT SO EVERYONE NEEDS TO LISTEN!!”
  6. In effect, sabotaging the team
  7. Years?
  8. It’s not lost on me that the word “DevOps” has just the right mix of stop consonants and affricates (for English speakers, anyway) to really roll off the tongue… and I doubt it’s lost on our subconsciouses, either.