Dan Miser - Fine jar policies

Monday, February 21, 2005

There are plenty of things that can be done to keep a developer from making repeatable and preventable mistakes. So the question really is: What kind of fines motivate developers? I look at fines as not only a deterrent but a way to help improve the talent of the entire development team and build team camaraderie. I've read that people at Microsoft that break the build take the build process until the next person breaks the build, but for me, nothing says "fine" like monetary punishment. ;-)

The fines listed below are not exactly going to break someone's pocket, but it does hurt to go into your wallet and pay up. The fines accumulate in a fine jar until there is enough to bring in doughnuts for the entire office.

So, what do you guys use for a fine system?

Making wild claims without having or providing supporting evidence: $1.00
Not writing a test case to isolate a bug: $2.00
Checking in code that doesn't compile (including hints/warnings, and active database connections at design-time): $2.00
Losing the IFDEFs in a DPR (typical when doing Add To Project in the IDE): $1.00 per DPR
Checking in code that causes users not to be able to run (typically done when not testing first): $1.00
Modifying editor options without prior approval: $1.00

Monday, February 21, 2005 3:05:00 PM (Central Standard Time, UTC-06:00)

Tuesday, February 22, 2005 12:22:00 AM (Central Standard Time, UTC-06:00)

Fines sound like a constant negative system (scare your users into working) which goes against how I do things, which is contant positive system (provide bonues and rewards for working well).

At the end of the day if your devs are scared to do anything they will be slower and try less to innovate, which is a bad thing.

Here is two examples of how I would do this.

a) Making wild claims without having proof - Hell the noobs do it all the time, send it around the office for everyone to get a good laugh. At the same time it lightens the tension, and everyone knows about the noobs mistake, which means they are less likely to do it again

b) Not writing test cases - How about bonuses to the devs that write the most test cases?

Obviously with some ppl this does not work and then going the negative route is the only way, but a positive route should be first.

Robert MacLean

Tuesday, February 22, 2005 11:08:00 AM (Central Standard Time, UTC-06:00)

I certainly see your point on negative vs. positive re-enforcement. My hope is that we have framed things such that this isn't a pure negative. It's more of a peer-pressure check, and fines are joked about from top to bottom.

Dan Miser

Wednesday, February 23, 2005 5:08:00 AM (Central Standard Time, UTC-06:00)

So, you're finally copying Singapore's policies? ;o)

BTW, check your GMail.

Chee Wee

Monday, April 04, 2005 5:41:00 PM (Central Daylight Time, UTC-05:00)

Hey, "Losing IFDEFs in DPR" fines should go to Borland ! <g> Will ever the IDE respect IFDEFs in dprs and dpks ???

David Berneda

Monday, April 04, 2005 7:09:00 PM (Central Daylight Time, UTC-05:00)

Hehehe. Good point, David. I know it's Borland's bug, but since the developers do, too, it now falls on us to keep the code working.

I know this issue is <a href="http://qc.borland.com/wc/qcmain.aspx?d=8718">logged in QC</a>. Let's hope a version in the future fixes this. Get the word out and vote!!

Dan Miser

Comments are closed.