I read an idea for increasing productivity in a company. It went like
Have a certain fund, that will be a bonus. Say $100,000. For each tangible bug found, the testers get paid $5 - $15. Whatever's left
over at the end of the month/year goes to the Devs.
It seems like a wonderful enough idea in theory, though I'm not sure
how well it will work in practice. The obvious consequence of this, is
that it promotes antagonism between Devs and testers. The bug business
becoming a zero sum game.
Is the antagonism a bad thing? How will it affect productivity, and
more importantly the organisation? Personal experience will be highly
(I cringe when I read "motivational" schemes like this.)
Perhaps the author of this idea defines "productivity" differently than I would.
The goal of most companies producing software is to make money, and perhaps maximize the amount of money they make. The goal of a bug bounty system is less clear, and certainly has nothing to do with productivity. A lot of time would be spent trying to get bonus money, and little time would be spent trying to ship the software (which is how the company makes money).
Imagine a company having one developer and one tester.
If you were the developer, your optimal strategy would be to withhold all software from the tester until there were no bugs remaining at all, or until there was no time in the schedule for the tester to find any.
I worked at a company that rewarded developers with praise, rather than money, and that was exactly the strategy used by one developer. Builds were released to QA every 2 weeks. And every other Friday, we had a full-team meeting where the bug count in the current build was announced. If a developer ever had zero bugs, that developer was singled out and praised for doing a great job.
One developer decided to game the system. She would hold the build (always having reasonable excuses) until just before the weekly meeting. She then released the build, the bug count report was run, and "magically" she had a zero bug count just in time for the meeting.
While she was a good developer, her code wasn't any better than most others. Her cleverness was in manipulating the system to her advantage.
I currently work in a shop that punishes Developers for the number of bugs attributed to their work during a project. They are expected to "improve" their bug count from the prior year. This is part of their MBOs, and part of what goes into their annual bonus payout.
Unsurprisingly, they have taken a long time to produce the first testable build for QA. And they asked that QA spend a lot of time testing in the Dev environment (where bug reports cannot be written). They have been given every chance to produce fewer bugs in the reporting system, and hence to maximize their bonus.
The Product Manager has even decided to change many bug reports to "enhancement requests" so as not to impact developer MBOs. His argument was "well, the developers haven't fully developed that feature, so they will enhance it when they have time".
If I were getting paid "by the bug" I could find a ton of bugs quite easily, no matter how good the developer. (I've been doing this work for almost 30 years). I'd focus initially on the low hanging fruit and skip anything that was time consuming at all. My bug reports would be minimal and not very helpful - basically whatever it took to enter the bug report in the system and get the cash.
The result would be a lot of superficial bug reports that were "just tangible enough" and the software would inevitably be left with some major critical bugs. I can't imagine the system would ever ship.
The developers would focus all their time and attention on new code. There would be absolutely no financial benefit in fixing any bugs that were already found. And they would be given incentive to produce tiny, insignificant releases. If they produce a release containing only a single line of perfect code, they get a $100k bonus! Why add any tricky features at all?
Both teams would argue vehemently about each and every bug report and if it was truly a "tangible" bug or not. (That's a nice and fuzzy term. I'd love to hear a team try to define it concretely). These sorts of arguments don't set the stage for anything I'd call productivity.
And neither testers nor developers would spend any time on anything else. No meetings, no documentation, no customer support, no helping others, no prep for shipping. Hey, if it were important, there would be cash attached to it, right?
And this last part is significant. For knowledge workers, often attaching cash bonuses to tasks they intrinsically feel are important is a big disincentive. If you want a greater understanding of the kinds of dysfunction that can arise from these sorts of incentive systems, I highly recommend you read Measuring and Managing Performance in Organizations by Robert D. Austin.
In short, this is a terrible idea.
Most good software companies recognize the folly of such a plan and try to stay away from this sort of system. Most software companies understand that releasing software with zero bugs isn't a realistic goal, and that it's more important to release software in a timely manner.