2y ago

Researchers found the top 10% of engineering orgs keep pull requests under 105 lines of code. They analyzed 2,000 dev teams and also said a rework rate under 8% and a daily+ deployment frequency put d

devinterrupted.substack.com

Inside the Workflow Metrics of Elite Dev Teams

18 comments

All this talk of elite makes the article so annoying to read and makes it difficult to take seriously...
- I only open 1337 PRs with 1000+ lines of code changed, and 0% test coverage.
  
  Just whipped up a slack bot to override the pipelines and automatically merge your pull requests
  
  my code is so 31337 u cant even code review it, it's classified "secret high intellectual technology" code.
- I kind of agree. Hard to take too seriously with that kind of verbiage.
- Nothing says elite more than how this article is set in a monospace font. Truly ELITE
Hi! Please don't link anything from this subdomain again. It was considered a plague back on Reddit, and this sort of content-free post shouldn't be encouraged here either.
- oh look, the fun police are here
This really devolves into "good teams can deploy daily, can raise a small PRs and have small number of rework". And this is like... thank you, but it is obvious. If team is able to do this things constantly it is probably a good team.
DORA says that if your team is able to do same pattern (as they show) it will be "elite/good" team. This really smell like a cargo cult. And managers are already using DORA metrics as good/bad teams metric.
This is clear Goodhart's Law case: ""When a measure becomes a target, it ceases to be a good measure". So either DORA knowingly did nothing to protect against metric gaming or they didn't considered impact they will make. Neither of those is a good in my opinion.
So yeah I don't like DORA in it current iteration.
- IIRC from the original report, the claim here is that even "gaming" these metrics leads to the desired result, as you can't game these metrics without actually improving your processes. I tend to agree.
What metric did they use to determine what “top 10%” means? Because that’s the part of this that seems most ridiculous to me given how situation-dependent most engineering decisions are. To illustrate with an extreme example: is “daily+ deployment frequency” a sign of an amazing engineering org if the thing being deployed is updates to your heart monitor firmware?
- Same problem with "top 10%".
  "DORA guys" came to our org in the past. And sing a song of "all successfully teams do that to, so you should too". One of the my question, that was left unanswered, was did they analyse negative scenarios to check if their suggestions actually works and add too the reducing cycle times and what not?
  And most of the time my cycle time is more depends on number of meetings I need to attend through day than on anything even remotely related to the coding.
  I understand what DORA tries to do, but what they achieve is just another cargo cult.
I don't know what DORA metrics is and it seems to be yet another bullshit discipline to give a name to "common sense." Yes, small commits are better to review and test, there is no need to create yet another "Agile" framework out of this with its blogs and certifications.
- But what are the consultants going to do?
Amusing to see a link to "Dev Interrupted" that gets interrupted partway through the development of its title :D

18 comments