Implementation of “Creating Change One Tic-Tac At a Time”

Those of you who came to CITCON London 2006 might remember the talk by Jeffrey of the same name (I have a couple of notes from back then, also see the entry for Agile 2007 conference and comments on Alistair Cockburn’s idea — Jeffrey & Alistair collaborated on that talk). This was also discussed at CITCON Brussels last year on a session arranged by Douglas Squirrel: Karma for Continuous Integration.

Essentially, the idea is that by giving token gifts to team members, you can get them to fundamentally change their working habits.

Well, redsolo has implemented a plugin for Hudson that does pretty much what Squirrel was suggesting: allocate points depending on what the developers are doing. The points are awarded or removed on build breaks, tests passing or failing, and on build successes.

Now, if I remember the discussion from CITCON Brussels correctly, the conclusion was that such a tool did sound like over-engineering a social problem. That was worth trying, so I asked for help on the CITCON Mailing List. Alexander Snaps was kind enough to give it a try with his team.

The outcome is that one of the developers was quick to point out that the point allocation was not entirely fair. This is an interesting result, because it shows that the points system works: developers do care (at least in the short run) about things as trivial as points. On the other hand, of course, it shows, again and again, that the devil is in the details: it is close to impossible to allocate points in a perfect way. You will always find another special case with a different point allocation pattern. Now, you could spend a long time trying to implement them all. But that this is really over-engineering…

Best would be to let the developers decide for themselves. Give them simple rules (one point per new successful test!) and let them request the point by themselves. They will figure out the details.