Tangible Devops - Easy?
Mar 24, 2020
4 minute read

Tangible DevOps - is it Easy?

SpeakEasy or SpeakHard?

Last Thursday I had the privilege to be the inaugural guest on the now virtualised DevOps SpeakEasy show . Hosted by none other but the mighty Kat Cosgrove and Baruch Sadogursky - the notorious steampunk fashion icons who also happen to be developer advocates at JFrog.

First of all - it really warms my heart how we suddenly get closer to folks from all over the globe due to COVID-19. Chatting to Baruch and Kat actually felt like we were sitting in the same room and for an hour made all the craziness of pandemic lockdown go away.

But beside being pure fun - the conversation was also very mind-stimulating. The SpeakEasy hosts are exceptionally good at asking the hard questions. They challenged me with an array of queries regarding the actual and conceived value of my consulting. They wanted to understand the tangible results of software delivery optimisation processes that we perform. And they asked for clear recommendations on how to deal with complexity.

My earnest attempts to answer all of these are in the video and the podcast. But I also want to reflect on this. Especially now this is becoming super relevant.

DevOps != Easy

Let me start with a declaration: even though we’ve been talking about DevOps for 10 years now - it isn’t becoming easy. It is hard to measure, hard to achieve and the ground keeps shifting under our feet.

And it definitely looks like in the new reality of reduced workforce and tightened budgets it will only become harder. Or rather - the gap between high performers and low performers will widen.

The Right Measure

In the interview (and in many talks I’ve given in the last year) I’m whining about how few companies actually measure the value of their DevOps initiatives. Even the data for 5 foundational metrics outlined in Accelerate is seldom collected and analyzed. That’s not to say that you can’t have a highly performing IT organisation without these measurements. But you definitely can’t be sure how well you’re performing or if you’re getting any better at delivering software without them.

I’m also suggesting that the reasons for not measuring this are purely psychological. It’s the same emotional blocks that prevent us from keeping budget or counting calories. Measurement is a process that requires discipline and may show discouraging results for quite a while. So we just say - “why measure? I’m doing all the correct things! In the end we’ll see the outcome”

The problem with this is that in complex systems the feedback loops are lo-o-o-ng and delays are tricky. So we may not see the result until it’s too late or until we’ve moved to another company. And when we do see it - it may be the total opposite of what we expected. But long before it becomes visible and glorious - very little increments in vital data occur that we can only see if we collect that data and analyze it. This data is one of the tangible results that the SpeakEasy hosts were so keen to uncover.

Touching the Untouchable

But this whole talk of tangibility sent me thinking again. Why are we in such a need of having “tangible” artifacts in such an intangible industry as ours? DevOps grew out of pain. But it wasn’t a physical pain - it was intangible. So the expected result of implementing DevOps would be the alleviation and prevention of that pain. And that’s not something that lies in the space-time continuum. For that we need totally different metrics. That’s why the subject that keeps returning to my mind is “Contentment Engineering” - i.e - IT engineering that is focused on keeping engineers happy. Should the most important metrics be around coder happiness? Simply because happy engineers create and run better software. All the rest is a neurosis forced upon us by the protestant work ethic.

I think they should. But that takes us to a much harder problem of measuring happiness. Softy-feely-touchy, is it?

But enough ranting for today…

If the intangible stuff intimidates you - we also talk about technology in the podcast: service meshes, contract testing, API evolution practices. I’ll write about all of these eventually. But again - ask yourself - how much more tangible is that?

And here's the video:




comments powered by Disqus