Should organizations penalize developers for defect reports filed against their work products?I was having a discussion with my friend where he asks if a manager taking the number of defects filed against a developer is justified. My take is no, because developers can introduce defects, but by holding those against him can cause unnecessary negative feelings in the developer's mind.What are the problems with penalizing developers based on defects that they inject? Does your organization penalize developers for creating defects in work products?
Should organizations penalize developers for the amount of defect reports filed against code they worked on?
productivity;development environment;bug;metrics
Sounds like it would do more harm than good. Ignoring for a moment whether it is fair for a manager to do that, let's look at the logistics...Problem 1: Are all bugs created equal?Developer 1 introduces a bug: Erases all customer data and curses at them.Developer 2 introduces two bugs: Form labels are not left aligned, and the calendaring feature is off by 1 second if an event is created that spans two leap years.So clearly developer 2 deserves more grief from their manager because they have double the bug rate. Of course not, so you come up with a bug rating system so developers with trivial bugs don't get dinged so hard. But wait, should the system factor in a modifier for a developer who is clearly making the same trivial mistake repeatedly and wasting the tester's time because they never learn from their mistakes? Maybe, hmmm. This is complicated. Problem 2: What counts as a bug?Manager - This report was supposed to include a running total, that's one bug for you!Developer - That wasn't in the requirements, that's a FEATURE not a bug.Problem 3: How do you group bugs?Developer - [Manager's Name], the testers filed 10 bugs against me because the velocities were incorrect on 10 different screens, but that was all related to a single bug in the getVelocity function. We argued for 3 hours about it, but they won't budge. We would like a sit down meeting with you to decide how many bugs should be filed. Oh and by the way, there is no way we are going to hit the code complete deadline tomorrow.Problem 4: More SLOC probably means more bugsDeveloper 1 sits on his butt all day, but manages to write 3 bug-free lines of code between arguments on Reddit over Arizona's immigration law.Developer 2 works hard all day and churns out a fully functional AI that won't kill John Connor the first chance it gets.So obviously you want to penalize the developer who makes more progress and/or takes more risks by innovating, right?SummaryThere are probably workable solutions to several of these, but as a manager of a programming team trying to meet a deadline do you really want to have everyone spending time arguing about what counts as a bug, what counts as a discrete bug, the importance of a bug, etc.? None of these things move your project forward and this will be poison for teams who will be forced to compete on issues that have no meaningful impact on the actual software being created. Not to mention what it does to your employee culture to focus this much effort on finding ways to make sure that every employee's mistakes are meticulously recorded so they can be thrown back in their face later.Inevitably you will have developers cajoling testers to work around your bug tracking system and report issues directly so they can fix them without it going in their PERMANENT FILE. Then you don't even have an accurate accounting of bugs or what people are really working on. Then there is the issue of adverse impact. That is HR talk for, you better have pretty good documentation before you start penalizing employees, especially financially. And if any of them are a protected class (minorities, veterans, women, handicapped, etc.) you better be triple sure that whatever system you have set up doesn't discriminate against one of them based on membership in that class (or that a judge could be convinced as such), even if it is just an unintended side-effect of the plan.So ultimately, you are not creating incentives to create less bugs, which is hard, but rather to negotiate away bugs by minimizing their importance or blaming them on someone else. Short Version No.