Should a salary bonus be based on bugs in released code or other metrics?



  • I've received a job offer recently with a significant portion of the pay based on yet to be determined "objective" performance metrics. We are supposed to sit down together after I've worked there awhile to develop and agree on the metrics that will be used. The only metric suggested by the employer so far is the number of bugs in released code. Is this workable? Is it a fair metric or, as I fear, will it introduce dysfunction? Are there other metrics that could/should be used? Some of the issues that concern me are defining what a bug is, who finds the bug (does it only count when the customer finds it?), how do bugs found in old releases count, does a bug caused by a requirements gap count, what happens when other people whose pay is not effected by this metric, such as developers, help out with testing before a big release, what about the conflict between finding all the bugs and getting the product shipped, etc. In other words, are there reasonable performance metrics that could be used?



  • Tying cash rewards to metrics like bug counts is always a very risky business, one that is almost certain to introduce dysfunction. I never want people on my QA team to have to worry about their bonus when I just want them to be doing the right thing. Imagine you are the tester working with a single developer (who happens to be your best friend) on a project that is planned to be released just before fiscal year end (when the bonus period ends). The developer has his bonus tied into getting this release done on time. You have a bonus tied into making sure the release doesn't have any bugs in it after it is released. On the day before the release you discover a not-too-serious bug. What do you do? You could stay silent, let the code get released so that your friend earns his bonus, and hope that the bug isn't discovered so that you earn your bonus. You could write the bug report immediately causing your friend to either argue and try to get you over-ruled or lose his bonus. This sort of thing happens all the time when bug reports are used as metrics and applied to bonuses. You have pointed out several of the flaws in using bug count metrics. Here's one viewpoint: http://www.allthingsquality.com/2010/04/misuse-and-abuse-of-bug-counts.html Release decisions are business decisions. Sometimes, it's more important to release code to meet an immediate business need - even if it contains bugs - and then fix the bugs later. You don't deserve to get penalized for that. Unfortunately, there are no good systems for individual bonuses that must be tied to "metrics". The thinking is that "if we tie his bonus to a 'metric', it will motivate him correctly, and will be an objective and fair way to measure him. This thinking is simply wrong. Yet companies know this and still continue to force manager to create such bonus programs, and everyone suffers. Trust me - it's no fun for a manager either. If you haven't already, you should read "Measuring and Managing Performance in Organizations" by Robert D. Austin. He talks about dysfunction caused by metrics/measurement systems. I want my team to be empowered to simply "do the right thing" in all contexts, without having to worry that it will cost them bonus money and without worrying how to game the system so they maximize their bonus. I strongly prefer that all bonuses are earned only based on company goals (sales and profit for example), and not on lower-level or individual goals. To me, this is the proper way to motivate individuals, and to reward them. Unfortunately, I've worked at many companies where I am forced to do otherwise. You won't be able to tell how this will work out for you until after you have accepted the job offer, and have been working there for over a year. Good luck!


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2