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

111–120 of 124 posts

Re: The ‘flawed five’ engineering productivity metrics

#111

Post by ajchida »

yodon wrote: post #81
dilyevsky wrote: post #76

Earlier quoted context omitted.

So you’re becoming “aware of what each other is doing” by half reading the pr title and going straight to approve button? I think “legitimately “ is doing a lot of lifting here too

You seem to presuppose that the people involved in the team conversations about these metrics are stupid or clueless to a point of willfulness or intentionally bad actors. If that's the case, as with the case where you're somehow able to approve your own CR's, you face problems unrelated to the numbers. If those are the kind of problems you face, you need to fix them well before you try to bring in any processes desi…

If you also measure the defects in production post release, we can co-relate the quality of CR and narrow down the bad actors

Re: The ‘flawed five’ engineering productivity metrics

#112

Post by kqr »

splittingTimes wrote: post #104
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…

They sure are nice, but how do you collect that data in an automated fashion?

Obvious follow-up: why do you need to automate it? You get decent precision by sampling just 10 % of what's going on. Depending on team size, that's manageable by just one person spending half an hour on it here and there.

And in the process of asking questions and poking around this person learns a lot about what's happening.

Re: The ‘flawed five’ engineering productivity metrics

#113

Post by dilyevsky »

ajchida wrote: post #111
yodon wrote: post #81

Earlier quoted context omitted.

You seem to presuppose that the people involved in the team conversations about these metrics are stupid or clueless to a point of willfulness or intentionally bad actors. If that's the case, as with the case where you're somehow able to approve your own CR's, you face problems unrelated to the numbers. If those are the kind of problems you face, you need to fix them well before you try to bring in any processes desi…

If you also measure the defects in production post release, we can co-relate the quality of CR and narrow down the bad actors

Imho if your intent for code review is to find bugs you’re doing it wrong.

Re: The ‘flawed five’ engineering productivity metrics

#114

Post by lordnacho »

the_jeremy wrote: post #85
lordnacho wrote: post #40

Earlier quoted context omitted.

You need idle time as an engineer. Otherwise if a higher value item appears in the pipeline after a lower value item you'll be working on the lower value thing first. Idle time is also where you do useful things like checking for updated dependencies, running a linter, generally reading up on the tech you're using, and making the code ready for future edits. Not so idle at all but not really the same as working on a…

Do you work somewhere that gives you this idle time? We explicitly have tickets for any tech debt or dependency updates we need to do, because otherwise we don't get time to do that.

I decide my own work so yeah. I realise not everyone gets that luxury.

Re: The ‘flawed five’ engineering productivity metrics

#115

Post by brazzy »

xyzzy4747 wrote: post #68
brazzy wrote: post #25

Earlier quoted context omitted.

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…

"intuition"? Seriously?

You're completely failing to answer the question.

Re: The ‘flawed five’ engineering productivity metrics

#116

Post by koliber »

hinkley wrote: post #93
koliber wrote: post #23

Decision making purely based on such metrics is wrong. It's management by numbers, and similarly like coloring by numbers, while relatively easy, will not produce great results. At the same time, metrics do have a place. Even flawed metrics, like the ones this article describes can provide value. When used together with qualitative evaluation and thoughtful analysis, it provides a more complete picture of what is goi…

Metrics are for asking questions, not answering them.

I like this a lot. Did you get that from somewhere, or did you come up with it on your own. It's captures the spirit of my metrics philosophy really well.

Re: The ‘flawed five’ engineering productivity metrics

#117

Post by prepend »

dtagames wrote: post #74
prepend wrote: post #46

Earlier quoted context omitted.

This seems easily gamed by just producing lots of lines of code. Adding inline documentation would improve this metric. This does explain some absolute dogshit products IBM made as maybe they were optimizing for this metric by having 1000 lines when one would do. I’m bitter from having to decompile and debug websphere in the 90s and 00s. I think this runs into a problem is that programmers are good at minmaxing. So a…

Everything was peer reviewed, so no extra code. Also, every single line had a comment, so no padding with comments. On the "why they failed" aspect, 100 years is a pretty good run. There are lots of reasons IBM is less relevant today, but buggy software isn't one of them.

I’m sure it’s buggy software didn’t help and I think it contributed to IBM’s reputation for poor software.

Re: The ‘flawed five’ engineering productivity metrics

#118

Post by thraxil »

kqr wrote: post #34
Brian_K_White wrote: post #26

Earlier quoted context omitted.

What do I care about start to finish time? The only way to shorten that latency would be to have so many employees that they can all spend all day just waiting to pounce immediately on their inbox. It's just the same or worse waste distributed differently. A developer with a full pipeline seems the most efficient to me. Let there be 15 projects all in different stages of progress. It's fundamentally not a synchronous…

This is a common conflict! One perspective says that idle engineers cost money, so you should load up your engineers to 99 % utilisation with a huge backlog of tasks. The consequence of this is that tasks take, on average, months to complete because they sit idle most of the time, not being worked on. The other perspective is that idle tasks is what's expensive. Thus you must keep your engineers lightly loaded (say 7…

It's always kind of amazing that so many engineers (and engineers turned manager) have encountered enough queuing theory to understand that if they keep a CPU at 99% utilization, it will have a detrimental effect on task latency, but can't understand how to apply that same reasoning to engineer utilization.

Re: The ‘flawed five’ engineering productivity metrics

#119

Post by foolfoolz »

prepend wrote: post #43
foolfoolz wrote: post #32

velocity points is not useless. it can’t be used in isolation but points delivered by individuals is a great starting place to identify outliers in your org. generally if someone is delivering far higher or far fewer points they are making an outsized impact to the team (either positive or negative). it’s not perfect, you must take context with it, but with averages and on long time scales it’s quite reliable

I think velocity points are useful within a team over time. They are locally useful. But they are stupid to measure across teams or to compare teams or productivity. Velocity points are just an estimating tool, not a measure of value. It’s useful to know that a team usually produces 10 points per sprint but this sprint is 5 or 20. It just lets you know if your team is producing “normal” or not. It’s useless to try to…

yes. sprint points do not translate outside team scope

Re: The ‘flawed five’ engineering productivity metrics

#120

Post by Brian_K_White »

thraxil wrote: post #118
kqr wrote: post #34

Earlier quoted context omitted.

This is a common conflict! One perspective says that idle engineers cost money, so you should load up your engineers to 99 % utilisation with a huge backlog of tasks. The consequence of this is that tasks take, on average, months to complete because they sit idle most of the time, not being worked on. The other perspective is that idle tasks is what's expensive. Thus you must keep your engineers lightly loaded (say 7…

It's always kind of amazing that so many engineers (and engineers turned manager) have encountered enough queuing theory to understand that if they keep a CPU at 99% utilization, it will have a detrimental effect on task latency, but can't understand how to apply that same reasoning to engineer utilization.

An engineer knows where analogies apply and where they don't.

My pool of available work is not impacting whatever I happen to be working on at the moment. I am not doing 1 second of work on 60 different projects every minute.

Post reply on HN