Hacker News Reader

> 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?

View on HN

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.

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.

> 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.

Reply on news.ycombinator.com