3 ms·

Well, that's not that difficult. Have negative tokens for bugs filed, similar to loss of experience for dying in an RPG.

by donaq 17y ago

cousin_it 17y ago
It seems someone needs to read Joel's article on metrics: http://www.joelonsoftware.com/news/20020715.html http://www.joelonsoftware.com/news/20020715.html . Relevant quote: Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can't win.
- donaq 17y ago
  While I find Joel's articles interesting and often enlightening, I don't think "someone" needs to treat them as the Word From On High of software development or program management. Anyway, that's still not impossible to solve. After the design phase, reward for every module shipped, then deduct points for every bug reported by users. If the programmer is able to hide bugs such that they never manifest in production, I say all power to him.
  - cousin_it 17y ago
    Now the programmer has an incentive to make their subsystem hard to use, so users don't go there and report bugs. C'mon, add some more epicycles.
    - donaq 17y ago
      Why would the bug reporting mechanism be in a subsystem? Unless every subsystem had its own bug reporting mechanism, which makes zero sense. [Edit] Oh ok, I think I see what you mean. Well, firstly, if a subsystem weren't integral to the app, why develop it in the first place? Secondly, you could always track the usage of the subsystem and provide additional incentives for its success. Lastly, who says subsystems have to be directly accessible to the user? If tasked to write a module that runs in the background, one can hardly make it deliberately obtuse.
wlievens 17y ago
That would lead to a black market for defects. I've heard the stories.

Well, that's not that difficult. Have negative tokens for bugs filed, similar to loss of experience for dying in an RPG.

by donaq 17y ago

Well, that's not that difficult. Have negative tokens for bugs filed, similar to loss of experience for dying in an RPG.

cousin_it 17y ago

It seems someone needs to read Joel's article on metrics: http://www.joelonsoftware.com/news/20020715.html http://www.joelonsoftware.com/news/20020715.html . Relevant quote: Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can't win.

donaq 17y ago
While I find Joel's articles interesting and often enlightening, I don't think "someone" needs to treat them as the Word From On High of software development or program management. Anyway, that's still not impossible to solve. After the design phase, reward for every module shipped, then deduct points for every bug reported by users. If the programmer is able to hide bugs such that they never manifest in production, I say all power to him.
- cousin_it 17y ago
  Now the programmer has an incentive to make their subsystem hard to use, so users don't go there and report bugs. C'mon, add some more epicycles.
  - donaq 17y ago
    Why would the bug reporting mechanism be in a subsystem? Unless every subsystem had its own bug reporting mechanism, which makes zero sense. [Edit] Oh ok, I think I see what you mean. Well, firstly, if a subsystem weren't integral to the app, why develop it in the first place? Secondly, you could always track the usage of the subsystem and provide additional incentives for its success. Lastly, who says subsystems have to be directly accessible to the user? If tasked to write a module that runs in the background, one can hardly make it deliberately obtuse.

wlievens 17y ago

That would lead to a black market for defects. I've heard the stories.