Ask HN: How do you measure eng team productivity?

Re:Ask HN: How do you measure eng team productivity? by toast0 on Monday July 31, 2023 @06:47AM (#36940826)

> However, anything that does not bring obvious value (bug fixing, refactoring) should be counted out of output in terms of productivity

Not counting refactoring as output makes sense, because it's more of repositioning for future output, and/or recreation.

But if fixing bugs doesn't bring value, why do you do it?

[ Parent | on HN ]

Re:Ask HN: How do you measure eng team productivity? by flavianh on Monday July 31, 2023 @08:09AM (#36941420)

Well, productivity measures how fast you deliver new value. Fixing a bug is about repairing value that you thought you had delivered but actually did not. Counting bugs as "value" would be double counting.

[ Parent | on HN ]

Re:Ask HN: How do you measure eng team productivity? by sirobg on Monday July 31, 2023 @09:04AM (#36941946)

I understand your point, but by doing this you will probably end up with nobody in the team caring about fixing bugs.

That's a problem because sometimes fixing bugs brings more value than adding a new feature or optimizing something.

[ Parent | on HN ]

Re:Ask HN: How do you measure eng team productivity? by magicalhippo on Monday July 31, 2023 @08:20PM (#36950730)

> Fixing a bug is about repairing value that you thought you had delivered but actually did not.

In that case it's important to classify issues correctly. Email sending worked yesterday but not today because Office365 changed some SMTP requirements (say ciphers)?

Customer will call it a bug, but according to your definition it should be classified as a feature.

[ Parent | on HN ]