DEV Community

Developer Experience is Dead: Long Live Developer Experience! 🫠

Justin Reock on February 14, 2024

Right now, here in early 2024, we seem to be experiencing YAPP (Yet Another Productivity Philosophy), and that philosophy is converging on develope...

Read full post

Ben Halpern • Feb 18 '24

Great read

Benoit COUETIL 💫 • Feb 19 '24

Such a nice and deep post my friend, thank you.

I will have to read it several time to grasp everything, especially the external links. For now, i do not agree with everything, but that is the beauty of diverse views.

Developer Experience around me have been my profound will for the past 18 years, and the main problem is poor management afaik.

A few things come to mind, that I'm not sure you addressed... And you seem so knowledgeable in the field that I might look ridiculous, but I will try anyway.

1) DORA is indeed technical delivery metrics at the core, which can lead to burn-outs if misused. But it can serve different purposes. I has helped me advocate to managers that "quality ultimately means more revenue on top of nice quality of life".

2) Shipping fast with good tools is a first step for more interesting talks, and is wanting by lots of (good) developers in my experience.

3) is there really a need of metrics for DevEx ? It is a matter of people, could we just ask them what they think ?

4) Shipping fast will never surpass shipping the right things, no matter the DevEx. Ingeneers tend to be happy to solve a wrong problem.

5) Burn-outs is also a matter of technical leadership. It is the role of the trusted ingeneering leaders to give boundaries to managers. Ultimately human problems have to be solved too, not just tech ones.

What do you think ?

Justin Reock • Feb 21 '24 • Edited

Thanks Benoit, I really appreciate your thoughts on this and I'm glad you are finding these posts to be insightful -- I think disagreement is really important right now too, as I think the entire industry is seeking thought leadership and the "right" way forward for platform, devex, etc, so we need to start answering these questions accurately. I'll do my best to respond, I think these are very thoughtful observations!

Agreed, I didn't mean to imply that DORA is bad, even though the tone of the article is playfully critical. DORA is a really effective distillation of dozens of important metrics, and it can help us tell an important part of the DevEx and productivity story. But even DORA was created within the SPACE framework, and so it also by definition only fills in one part of the overall image. I think the challenge for management is that human and socio-technical metrics are really hard, and there are a lot of invisible tensions and dependencies between them. That's why I think portals are such a smart solution, is that they allow us to create a picture of DevEx that is inclusive of DORA and other important data like on-call data, developer productivity engineering metrics, unexpected escalations and other sources of toil, etc, and allows us to explore the way those metrics are transitively related.

2) Shipping fast with good tools is a first step for more interesting talks, and is wanting by lots of (good) developers in my experience.

I think that's right, in that Deployment Frequency tells us a lot about the health of the underlying delivery pipeline, and Throughput, in the context of the Theory of Constraints, is the most important component of a complex system and it should always be optimized for with the highest priority. But, Throughput is distilled from hundreds of other measures, including the more human and DevEx or Developer Productivity Engineering metrics, so I think they are actually included in that picture, we just haven't been painting a high enough resolution picture to see where those data fit.

3) is there really a need of metrics for DevEx ? It is a matter of people, could we just ask them what they think ?

Qualitative metrics are important, and we can get very creative about how we capture those metrics, through microsurveys, etc, to try and keep things accurate and avoid survey fatigue. I think that's all important, and when we use a framework like SPACE to normalize those metrics, we get another very important part of the story. It's still not the full picture though, and so we still run the risk of making poor business decisions off of incomplete data. For instance, we already know that cognitive fatigue can skew survey data, rather confoundingly. Burned out teams tend to correlate with toxic management, and this can chill qualitative results. On the other hand, highly productive teams tend to communicate more, and so survey bias favors them. We should survey our developers and collect qualitative metrics, but we should look at those metrics and find the tensions that exist with quantitative ones, which can help us discover problems that were not visible because we weren't capturing all of the right data and correlating it.

4) Shipping fast will never surpass shipping the right things, no matter the DevEx. Engineers tend to be happy to solve a wrong problem.

Agreed, again, that Throughput is the most important metric. I would say though, that here in 2024, the biggest bottlenecks to throughput seem to be in DevEx, as automation and DevOps tooling has removed a lot of the bottlenecks that were present a decade ago, especially in the most elite engineering organizations. This can include bottlenecks to delivery caused by cognitive fatigue and developer burnout, which we know is rife, and absolutely is part of the critical path of the value stream. With scale it may no longer be the most critical part, but, it is still tied to TTM and revenue, and hasn't been solved for in the ways that CI/CD, cloud app delivery, etc, have been.

5) Burn-outs is also a matter of technical leadership. It is the role of the trusted engineering leaders to give boundaries to managers. Ultimately human problems have to be solved too, not just tech ones.

Absolutely, technical leadership is accountable for burnout, especially when this is a problem that's been mostly just ignored and not fully solved for, so there's high potential for improvement. That's the chip on my shoulder for this article, actually, that we have been speculating long enough, and its time for technical leadership to start making real investments, and making room in budgets, for the right types of human / socio-technical solutions.

Thanks again Benoit for your thoughts and your kind words, I really appreciate this dialogue, we have to solve these problems, so much is riding on our workforce!