Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ‘flawed five’ engineering productivity metrics

leaddev.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: The ‘flawed five’ engineering productivity metrics

#61

Post by cbozeman »

brazzy wrote: post #25
shakezula wrote: post #13

For fuck’s sake, can we just stop trying to measure developer productivity like we’re an assembly line?

So how do we measure it?

The same way you accurately measure anything... with a lot of hard work and attention to detail.

The best physics professor I ever had assigned a fuckload of homework every single day of class and graded it all himself. He probably worked 65+ hours a week, minimum. But you got feedback on all homework and that gave you an understanding of how well you were grasping concepts and on what you needed to work.

Re: The ‘flawed five’ engineering productivity metrics

#62

Post by kqr »

feoren wrote: post #55
yodon wrote: post #12

My favorite quantitative metrics for engineering teams: - Avg time from code review requested to code review picked up - Avg time to complete code review - Avg time from eng done to first customer using it - Avg time from eng done to full production release - Fraction of tasks started that never reach a customer These are loosely based on the Japanese concept of Muda (waste), as personified in the physical logistics…

> - Avg time to complete code review Doesn't this depend heavily on the size of each PR? Sometimes it makes sense to have small changes, sometimes to have sweeping refactors. These would have vastly different times to complete a code review, for reasons unrelated to team productivity.

Have you measured this in your organisation? In my experience, every team has a fairly distinct cut-off point where if you make PRs larger than that, they start to hang around in someone's review queue forever.

Every time I've made a larger PR I've regretted it and subsequently split it up into smaller ones. I get higher quality feedback and faster feedback to boot that way.

Re: The ‘flawed five’ engineering productivity metrics

#63

Post by jameshart »

All of these metrics are like trying to measure progress on a building project based on the volume of noise produced.

‘I don’t hear hammering! There should be more hammering!’

‘Lines of code’ is a useful metric for ‘likely ongoing maintenance cost’. ‘Impact’ is a good proxy measurement for ‘likelihood the change introduced a bug’.

If you encourage teams to increase those numbers you will get what you deserve.

Re: The ‘flawed five’ engineering productivity metrics

#65

Post by ftio »

I worked as a PM on internal developer productivity at Google for a few years. As I've said in previous comments, compared to my former colleagues, I'm an infant in this area, so take this with a heaping of salt. (Opinions my own.)

I do not believe in the possibility of a "General Theory of Productivity," and management-by-numbers-alone is actively harmful, but I do believe in the possibility of measuring productivity in a useful way. Even "bad" metrics like commits per engineer per week can be useful at the right granularity, e.g., to do high-level velocity forecasting over a large, representative group of engineers during different times of year.

If you're wondering: different metrics are suited for different use cases, but as a baseline, I think the DORA metrics[1] are a reasonable starting point.

1. https://cloud.google.com/blog/products/devops-sre/using-the-...

Re: The ‘flawed five’ engineering productivity metrics

#66

Post by xyzzy4747 »

Traubenfuchs wrote: post #52
xyzzy4747 wrote: post #4

The best metric is your own intuition about how productive people are being and their output, subjectively thinking about the quantity, quality, and impact. It becomes pretty obvious who is contributing a lot and who isn’t. You don’t need to track metrics.

This also doesn‘t work and just gives social, extroverted and eloquent people a huge advantage.

Not really. If social and extroverted people provide more value to the company, they should get better performance reviews and paid more.

Re: The ‘flawed five’ engineering productivity metrics

#67

Post by puchatek »

yodon wrote: post #12

My favorite quantitative metrics for engineering teams: - Avg time from code review requested to code review picked up - Avg time to complete code review - Avg time from eng done to first customer using it - Avg time from eng done to full production release - Fraction of tasks started that never reach a customer These are loosely based on the Japanese concept of Muda (waste), as personified in the physical logistics…

Just the fact that these are team-oriented and not individual-oriented makes them above average valuable already

Re: The ‘flawed five’ engineering productivity metrics

#68

Post by xyzzy4747 »

brazzy wrote: post #25
shakezula wrote: post #13

For fuck’s sake, can we just stop trying to measure developer productivity like we’re an assembly line?

So how do we measure it?

Imagine you own a small company (I actually do) and the company's money is basically your money.

Now imagine who you want to pay to do stuff and how to measure them. The best way is to see their actual performance unfold before your eyes and use your own intuition. See who gets things done and who doesn't. Who needs more handholding and who can work more independently. Some workers are much better "deals" than others from a company perspective.

Re: The ‘flawed five’ engineering productivity metrics

#69

Post by cwilkes »

madcaptenor wrote: post #33

My kid is figuring out pooping in the potty. We have a chart where we make a check mark when she does it. She likes check marks, especially when she can make them herself. Over the past couple weeks her poops have gotten smaller and more frequent.

Sounds like she’s going up for promo!

Re: The ‘flawed five’ engineering productivity metrics

#70

Post by mdoms »

feoren wrote: post #55
yodon wrote: post #12

My favorite quantitative metrics for engineering teams: - Avg time from code review requested to code review picked up - Avg time to complete code review - Avg time from eng done to first customer using it - Avg time from eng done to full production release - Fraction of tasks started that never reach a customer These are loosely based on the Japanese concept of Muda (waste), as personified in the physical logistics…

> - Avg time to complete code review Doesn't this depend heavily on the size of each PR? Sometimes it makes sense to have small changes, sometimes to have sweeping refactors. These would have vastly different times to complete a code review, for reasons unrelated to team productivity.

Large PRs are one of the most serious anti patterns in day to day work.
Post reply on HN