Hacker News Reader

Comment by hliyan | Hacker News Reader

I posted this comment in response to the previous submission [1] of this same "paper":

Also note that the prior work they repeatedly cite (no less than 5 times in as many paragraphs, and indirectly referenced several times in relation to the 20+ "sociotechnical factors"), i.e. reference number (9), is based on "semi-structured interviews with 21 developers". While a lot of the observations and recommendations are correct (and are obvious to any seasoned engineering manager), this seems like an academic exercise in picking three somewhat disparate aspects of development and trying to fit them into a geometric shape (an equilateral triangle) and then calling it a framework.

1. https://news.ycombinator.com/item?id=36006561

View on HN

This by the same team who brought you the DORA metrics and the SPACE framework. I suspect it is really a vehicle to sell books and consulting, despite the article largely making sense.

Maybe it is atonement of some sort.

Thanks for pointing that out. Although I do think DORA metrics make some sense, it seems like an unnecessary framework considering what the folks in queueing theory have done over the years.

Anyone claiming we need to invent our own metrics needs to read Reinertsen.

I'm sure you have seen it already, but there has been some sound criticism of the DORA metrics: https://isthisit.nz/posts/2022/state-of-the-dora-devops-metr...

Though I disagree with Logan about the change failure rate (see https://two-wrongs.com/you-can-reliably-measure-change-failu...), I still think he is spot on in terms of MTTR.

Strongly seconding Reinertsen for anyone interested in this, though. I think this article of yours is particularly insightful and of high quality: https://lucasfcosta.com/2022/08/31/engineering-metrics.html

Well, yes, taking established findings and twisting them into a memorable or easily usable shape is what one does when trying to popularise concepts. (E.g. how the Shewhart/Deming cycle is related to the scientific method, or how the cost/speed/quality triangle restates "everything is a trade-off".)

That says very little substantive about their results, though, so I'm curious how you think that matters to the discussion of developer productivity!

> Although DevEx is complex and nuanced, teams and organizations can take steps toward improvement by focusing on these three key areas.

I feel like they are aware that not everything fits into the framework perfectly, but if your organization was trying to improve DevEx, this framework is a place to start.

Reply on news.ycombinator.com