As with everyone else so far, I'm pretty much against this. A couple reasons come to mind:
Most companies allow business to pressure/control software development. What I mean is very few places ask a developer how long it will take to do something, and then let him have that long. You give a timeline that the product owner doesn't like and you're likely to face pressure from them to get it done earlier.
While it's still the developer writing bugs, there are a lot of forces at play. He doesn't want to get dinged for not meeting business demands. But if they keep pressuring him to write a feature in 1 day that should take 1 week, you can bet there will be bugs.
With multiple tiers or layers of software, a bug could be found in the upper layer but actually caused by something lower down. Additionally, "bugs" could be introduced because the layers misunderstood what the other was doing.
Decrease in productivity
Actual productivity will tank as you now not only have to QA the project, but also take time to figure out the true root cause and person to blame. While this might seems simple, I'd wager that it will blow up into something bigger. If my performance is based on me not getting any bugs and you're trying to assign a bug to me, you can bet I'm going to argue that it's not. This isn't going to be a simple email that says "This was John's fault not mine." Because now John is going to respond. In the end, you'll be sitting in hours long meetings at least once a week trying to sort through all the bugs.
Developers need to be professional
Approaches like this tend to diminish the professionalism of developers. Think of CEOs, they're often evaluated on the overall growth of the company, right? If they lost a $100k a year customer, that might be bad, but it's often downplayed if they still grew the company by $500k that year.
Plans that try to tie developers to metrics like these (number of bugs released, or number of lines of code written, features released, tests written etc) take developers from the realm of a professional employee and place them in the category of hourly worker.
Imagine you have an hourly worker mailing letters. His goal might be 100% accuracy, and you decide to dock him 1 point for each letter he screws up.
That's essentially what you're doing to developers. You're taking a group of people who are typically:
- Passionate about their work
And you're turning them into factory workers. They'll start "punching the clock." They'll start looking quickest easiest way to do something RIGHT NOW with no thought to how it will play out in the future. After all, why build an entire sum routine when I can just hard code the values for 1*1 to 12*12. That way I know there are no bugs.
All that in mind, however, I am NOT saying that developers should not be held accountable. I absolutely think they should, and honestly, any developer worth keeping around isn't going to want to release bugs. If you have developers that don't mind releasing bugs, you should fire them right now (seriously, do it before lunch.)
I cannot think of any other professional environment or occupation where people try to apply these types of metrics to one another.
If a manager cannot tell who his top performers are and who is bottom performers are then that person should not be managing software developers, because he/she is clueless.
Before you apply a metric, you need to spend a LOT of time getting the right one, or else you risk running off your top performers since they don't want to be treated like little kids or assembly line workers (and in the end you might decide to not have metrics.)