Timeline for How do I measure employee (software developer) performance based on bugs created?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 3, 2012 at 10:07 | comment | added | Wolf5370 | There are of course design flaws, but these can hardly be called bugs. Shopstoppers could end a project, bug again this is almost always down to problems at the analysis stage (or scopecreep). Bugs, as far as I define them at least, are just coding mistakes (typos, logic errors etc) and not design errors; thus can always be fixed (whether it's viable to or not is another question). | |
| Apr 1, 2012 at 2:35 | comment | added | jmort253 | @Wolf5370 - You mentioned a very great point. Buggy software isn't the same as a bug in hardware, like the chair in your example. Bugs in software can just be fixed. A bug is basically an unfinished feature. It's not like the entire project has to be scrapped and started over because of a bug, not like if it were a buggy circuit board design or a car alternator... | |
| Mar 30, 2012 at 6:36 | comment | added | Wolf5370 | I don't disagree that such metrics as a performance review indicator is silly, this is why I specifically stated "as a team". I meant it in a pat-on-the-back sort of way rather than bonus linked etc. As my final comment suggested, KPI on peformance relating to bugs is never useful. I did get that you spoke toungue in cheek, but I guess we'd be surpised how many PMs out there would believe such a scenario not only possible but likely. I was a developer a long time, I would never have left a showstopper to go through the system knowingly - I would much rather go cap in hand to the PM. | |
| Mar 30, 2012 at 6:10 | comment | added | Andrew Shepherd | The comment was tounge-in-cheek but it points to a flaw in the metric. A team that creates bugs and fixes them scores better than a team that gets it right the first time. Imagine a developer has spent five days working on a new feature. He's already surpassed his estimated time and just wants the feature finished. He can see a non-showstopping bug in this functionality. Does he spend the extra hour to fix the bug now? Or, does he mark the work as done, knowing it will be fixed some time in the future? If he knows that the latter option would help some score go up, then he'll leave the bug. | |
| Mar 30, 2012 at 5:22 | comment | added | Wolf5370 | I think this is a fallacy. It would be a pretty poor team and a very low team member that did this. For the most part people want to be professional. It is easy to say what you did, but I doubt you actually would do that. People generally liked to be though of as good at their job, and dislike to bring their team down. If team members did as you said, then there are much more issues with the team as a whole than individual performance. It would also not be hard to spot such an individual and much easier to remove them from the team. PM's do not just sit in an office looking at metrics. | |
| Mar 30, 2012 at 4:10 | comment | added | Andrew Shepherd | I disagree with "do it on the number of bugs fixed as a team, not raised". Put me on that team, and I will spend an hour each morning adding visible bugs that are easy to fix. Woo hoo - here comes my bonus! | |
| Mar 29, 2012 at 20:13 | history | answered | Wolf5370 | CC BY-SA 3.0 |