The ‘flawed five’ engineering productivity metrics
1–10 of 124 posts
Re: The ‘flawed five’ engineering productivity metrics
#2The most useful metric in my view, and one I learned at IBM, is fixes applied over shipped lines of code. Multiple fixes over the same lines of code is exponentially bad.
IBM started measuring code defects vs working code in this way because productivity studies they did showed that fixes took much more time per LOC than new code and had other costs (customer sat, doc changes, reputation) besides.
Re: The ‘flawed five’ engineering productivity metrics
#3The most useful metric in my view, and one I learned at IBM, is fixes applied over shipped lines of code. Multiple fixes over the same lines of code is exponentially bad. IBM started measuring code defects vs working code in this way because productivity studies they did showed that fixes took much more time per LOC than new code and had other costs (customer sat, doc changes, reputation) besides.
This is a variant of DORA’s change failure rate
Re: The ‘flawed five’ engineering productivity metrics
#4The 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.
Re: The ‘flawed five’ engineering productivity metrics
#5It's probably easier to measure anti productivity than software productivity.
Excessive or poorly timed meetings, scope change, poor WFH distraction management, excessive support load, etc.
I'd like to think that we can assume people will be productive if we set them up for it.
Re: The ‘flawed five’ engineering productivity metrics
#6Amazon promos and firings are based a lot around the amount of lines of code you write, the number of code reviews you do (and the percentage of the time you review when asked), the number of merge requests you have, and the number of iterations per review. If you average more than 2 iterations per MR, you're on the chopping block as it means you're "sloppy".
Its ridiculously dumb. I've heard those numbers matter less as you gain tenure and seniority. But for the new grads and lower level engineers, all the savvy ones were gaming these metrics. It sucked to work in that environment and was a big reason why I left.
Re: The ‘flawed five’ engineering productivity metrics
#7IMHO teams works best when they choose their own key performance indicators, and match these up with the real-world success of the team's users, customers, and stakeholders.
These kinds of metrics can involve people (e.g. add a feature to increase customer satisfaction by X points), performance (e.g. optimize a path to increases throughput by Y%), processes (e.g. fix a bug so security continues to match commitment Z), etc.
Re: The ‘flawed five’ engineering productivity metrics
#8The most useful metric in my view, and one I learned at IBM, is fixes applied over shipped lines of code. Multiple fixes over the same lines of code is exponentially bad. IBM started measuring code defects vs working code in this way because productivity studies they did showed that fixes took much more time per LOC than new code and had other costs (customer sat, doc changes, reputation) besides.
But ultimately, the outcome is that IBM is a dinosaur corp and no one looks to them for technical leadership of any sort. They don't deliver and they're not well known for writing particularly good code. So that calls the value of the metric into question.
Re: The ‘flawed five’ engineering productivity metrics
#9There's some for SRE's and Sysadmins too:
* Cost reduction; usually by a very arbitrary amount, despite you having no control over what's needed
* Uptimes; last job told me that I had to get 99.998% uptime, Googles global load balancer is only 99.9%
Re: The ‘flawed five’ engineering productivity metrics
#10Amazon promos and firings are based a lot around the amount of lines of code you write, the number of code reviews you do (and the percentage of the time you review when asked), the number of merge requests you have, and the number of iterations per review. If you average more than 2 iterations per MR, you're on the chopping block as it means you're "sloppy". Its ridiculously dumb. I've heard those numbers matter les…
> Its ridiculously dumb. I've heard those numbers matter less as you gain tenure and seniority. But for the new grads and lower level engineers, all the savvy ones were gaming these metrics.
The company care more about weeding out the really bad junior engineers than it does about rewarding the good ones.
Honestly I don't have a big issue with that because I've seen what happens when bad people stick around. It's never fun for the good people, though.