These days, there’s a lot of interest in measuring developer productivity. And rightly so since there’s a strong correlation between high performance software delivery and business success. Yet, I think there's a couple of problems with the so-called developer productivity metrics. - ThreadSky

crichardson.bsky.social • 9 days ago

These days, there’s a lot of interest in measuring developer productivity. And rightly so since there’s a strong correlation between high performance software delivery and business success.

Yet, I think there's a couple of problems with the so-called developer productivity metrics.

Comments

yacl.bsky.social•9 days ago

Same. Like using the number of PRs per dev per day as a key metric in the new Core4 model.

crichardson.bsky.social•8 days ago

Yes.

On the one hand, PRs/dev/day indicates that some things are working well.

But in their descriptions of the PR metric they seem to be missing a verb? Created? Merged? Merged into which branch?

crichardson.bsky.social•8 days ago

Also, and perhaps more importantly, just because a PR is merged into trunk doesn't not mean anything has been delivered.

Enterprises often have all kinds of long review/testing activities before the PR makes its way to production.

crichardson.bsky.social•8 days ago

I prefer the original DORA metrics - like all metrics they are imperfect but at least they measure getting stuff done.

yacl.bsky.social•8 days ago

Same. I like DORA + SPACE.

I am also a huge fan of Trunk-Based Development whilst pairing or even mobbing with the whole team (domain experts included). Often pushing directly to trunk - no PRs.

crichardson.bsky.social•8 days ago

Good point about skipping PRs although I like the ship/show/ask model.

https://martinfowler.com/articles/ship-show-ask.html

crichardson.bsky.social•9 days ago

To learn more, please see the article:

https://buff.ly/4b6AAKi

heygregory.bsky.social•8 days ago

I agree that some metrics are helpful. On the other hand, approaches to measuring productivity can have innacuracies based on assumptions.

crichardson.bsky.social•7 days ago

Sure. There are countless ways metrics can be misused, e.g. Goodhart's law.

As always, competence is essential.

davidmanheim.alter.org.il•4 days ago

I strongly agree with the point that competence is essential, and will point to my work on how to develop better metrics in general, which is a seperate but complementary skill to your key points about managing developer productivity: https://www.cell.com/patterns/fulltext/S2666-3899(23)00221-0

heygregory.bsky.social•8 days ago

One common assumption I’ve observed is management thinking fewer comments on PRs means the set of changes are at a higher level of quality than PRs with more comments. This misguided assumption doesn’t taken into account:

heygregory.bsky.social•8 days ago

1. Authors adding comments to clearly communicate changes beyond code comments and self-describing code.
2. Adding comments for questions to listen and learn
3. Adding comments for recommendations, when they are distinct from requests for changes.

heygregory.bsky.social•8 days ago

As a result, some team members leave less comments, leading to increased gaps in meeting functional requirements and increased risk. Approaches have to be updated to include intent, data from additional sources, and different analysis of the data to paint a more accurate picture.

Comments

Posting Rules

Reply