I experimented with this idea once, over a decade ago. Well, not exactly this idea, but a variation of it: For each bug in my code which I fixed, I paid the tester who found it.

The risk here would be that I would intentionally resolve bugs as INVALID (or WONTFIX or anything other than FIXED) in order to avoid paying the penalty for fixing them, but I like to think that I made my decisions on their technical merits rather than based on my pocketbook. Since the tester saw the bug resolution, there was a degree of oversight: If I used bogus bug resolutions to avoid the bug fixing penalty, the tester would just reopen the bugs. The amount of the reward varied based on the quality of the bug, so that encouraged testers to focus on finding good bugs instead of weenie ones.

However, I also believe Raymond left out the most interesting portion of this idea- What did he feel the result was? If he no longer does this (“I experimented once…”) I think we can assume the value to Raymond is lower then the cost of paying the rewards for every project. Which, of course, I find totally reasonable- I’d hate to self-fund a program like this on a large project!

Question for discussion- Would the proper method of rewarding QA and Developers for bug free code be based on the number of post-release bugfixes requested by Tech Support? That is, QA and Dev are free to file bug reports and fixes as normal, but each issue that causes a significant enough number of calls to Tech Support that Tech.Supp. asks for a bugfix (Tech Supp does track and provide that info for your environment, right? :-) reduces the “bug-free” bonus for QA and Dev.

To be fair, I’ve never worked under such a environment, but I think it would be interesting to do so. It is one of the metrics I like to use on my self-assessment at review time.

[It was a small project where I was the only developer, so when a bug was found, it was clear who should pay out… Assigning blame is harder when the project has N developers. (The shared pool idea is interesting though.) -Raymond]

The developers started off with x amount in their pot and for every bug, money was removed and the testers gained from it – their pot started at 0.

It worked because the devs didn’t want to create bugs, so tested a little more before releasing. The testers wanted money so they tested even more obscure test cases in order to find bugs.

If there was a massive difference (ie the devs actually managed to have something in their pot at the end of it), the testers were given consolation prizes (as developer’s succeeding means testers not).

This does happen inside Microsoft at a product’s level. The support organization provides extensive statistics per-product (# of incidents, minutes per incident, drill down according to root cause, etc), and it boils down to support cost. Then the product team – and their seniors – can compare revenue vs. support cost. A high ratio (more than 8%, I think) means the product has problems: Poor quality, poor usability, etc. A team can then invest in areas that have high support cost, in an attempt to reduce the support cost there. Our team has done that with great success.

It doesn’t get drilled down to the individual dev/QA person though. If it did, it would push people away from doing complex area to safe, easy ones. Also, the delay is to long – if a release cycle is 1.5 years, and customers’ deployment cycle another 2 years, by the time you get the support calls the original devs have more often than not moved on.

In my area, products are generally either simple enough enough that only one developer works on them, or the components are separate enough that it’s fairly easy to tell who the problem belongs to. I sometimes forget that it’s not that easy for everyone.

One of my biggest personal issues is that I often feel my products don’t receive sufficient testing before they go live.

Additionally, much of the Help Desk, including their manager, works not far from me. I make it a point to stop by and chat for a few minutes a few times a week.

As such, I’m very sensitive to the support costs of not catching a bug, and also very interested in various programs which help to uncover bugs.

Which is why I was hoping for a quick and simple clarification from Raymond. I’m not sure why I was hoping for that, but I was. :-) However, reading between the lines, I get the message “I found it valuable, but seldom work on projects of the scale this would work for”.

[I found it an interesting exercise but seldom work on projects where I’m the only dev. -Raymond]

Inside Microsoft, it is quite difficult to have good connection between the product team and the support personnel, which are scattered all around the world. Our team takes great pride in having accomplished that. I envy you for being as close to your helpdesk, and your helpdesk for being close to you.

Off-topic: You typo’ed my name "Jonathon" – can you think why? Other native English speakers have also made this mistake, and were never able to explain why when I asked. I’ve been trying to find out for year!

Jonathan- I had to actually look twice to see the typo. And, in fact, I had to correct it when I wrote your name at the beginning of this paragraph.

I don’t know what to say, other then it’s an alternative spelling, probably similar to Mark versus Marc. A quick jaunt over to Bing says I’m in the minority. I wonder if it’s just English speakers from the Southern United States, or some other smaller subset subset of native English Speakers.

I chose Southern United States because, at least where I grew up, the name Jonathon (And/or Thomas, Jonathon Thomas and Thomas Jonathon being a common pairing of names) was probably a reference to Thomas Jonathon Jackson, AKA "Stonewall" Jackson. He was a military leader in a failed revolution that occurred here in the US who is particularly considered a hero in certain areas, for various reasons probably too complicated and way too off topic for this particular forum.