Ever heard of a company awarding bounty points for bugfixes? Making team members work to do the most, as some bonus money will be dependent on it? Having them split, or pay bounties to others to test, so they don't 'lose' points when it reaches a UAT environment?

I heard this from management for the first time today. To me, it sounds like a pretty ridiculous approach to software development. It sounds as if the team members will be competing with each other in a non-productive way, essentially slashing the productivity they've got going now.

Any thoughts? Have you ever seen something like this actually work? Did it help or hurt the team?

UPDATE 4/6/11: This approach was cancelled due to feedback from the whole team! I'm happy to learn that it wasn't just me thinking it wasn't a great idea.

  • 3
    There's a mildly interesting book called 'Drive' that talks about exactly these kinds of perverse incentive systems.
    – RSG
    Mar 29, 2011 at 2:27
  • 1
    I feel sorry for you, your boss is an idiot.
    – HLGEM
    Mar 29, 2011 at 15:12

4 Answers 4


Yes, I really have seen this.


  • Excellent! I had totally forgotten this one!
    – reallyJim
    Mar 29, 2011 at 2:25
  • Yeah, there's a letter in one of the Dilbert books from someone who's company tried this. Apparently they stopped it after 1 programmer claimed something stupid like thousands of bucks in a couple of weeks :-)
    – James
    Mar 29, 2011 at 13:43
  • They tried a version of this at my work before my time :) it worked as well as you would expect.
    – Job
    Mar 29, 2011 at 14:05
  • I would print this out and post it prominently where your boss and especially his boss can see.
    – HLGEM
    Mar 29, 2011 at 15:15
  • Picking this as an answer, as it seems most appropriate!
    – reallyJim
    Apr 6, 2011 at 15:10

Every reward or bounty creates an incentive to "work the system". Be really careful of the side effects.

Two that I can think of:

  • If you reward bug fixes the team will discover more bugs. And spend more time fixing bugs even though they might be really minor defects in favor of producing important business features.
  • The competition could create some unhealthy behaviour - something along the line of "I won't work on that part of the code because I know I'll loose bug points".

Generally I like to focus on positive points (i.e. what we have delivered) rather than the negative (i.e. bugs where we screwed up).

  • +10000 - this post lists the exact reasons you shouldn't do this
    – ozz
    Mar 29, 2011 at 10:39
  • @leonm: And you have forgotten actually introducing "innocent" bugs to fix, asking QA to open multiple bug reports for slightly minor variations of the same issue, the tendency to patch the symptoms rather than the cause because symptoms are numerous... and of course leaving out the real bugs because they tend to take a lot of times to fix. Mar 29, 2011 at 17:57

It will hurt the team, and the product. Many of the developers will focus on the easiest, most trivial bugs they can find so that they can collect the bounty with the least risk.

Or at the worst, developers will conspire to game the system: http://thedailywtf.com/Articles/The-Defect-Black-Market.aspx

A place I used to work at, shortly after I was eliminated, had a contest to try and reduce the amount of bugs in the code base. The winner would receive a gift card or something like that. All it ended up doing is annoying all the developers because one guy did just what I mentioned: he racked up a huge amount of "fixed bugs", but he focused on the trivial stuff.

Now, noone wanted to fix any bugs because they couldn't catch up to the leader because all that were left were the real, difficult issues waiting to be fixed.

And the worst part, is that before the contest, everyone wanted to fix all the hard problems, because every developer wanted to ship a high quality project. It took awhile after the contest to restart that enthusiasm. The contest killed that desire for awhile.


Quantative rewards stifle creativity and productivity.

This has actually been shown in some studies. A fixed, solid salary with resonable responsibility and correspondig authority works best to boost productivity in these type of jobs.

Mind-numbing and repetitive work (i.e. carry X sacks of grain from A to B), OTOH, shows a boost by paying for X amount of work done.) But it's hard to find such jobs in the developed world, and it's a race to the bottom for everyone. Useful in the short term, but not something you'd want a major part of your workforce to engage in, IMO.

And I hope you want motivated employees, not mindless drones applying minimum-effort fixes just for the money. (There's a big risk you'll spend time arguing about what is a fix and if it's a proper fix. I've seen enough of that bigotry from developers without monetary incentive, thank you.)

Not the answer you're looking for? Browse other questions tagged or ask your own question.