jeffelmore.org

I’m a big fan of metrics. We use Scrumworks at the office and we put our burndowns on a whiteboard so we can see how each sprint is going day-to-day. Having this feedback always available is both informative and motivating. But we only update the burndown once a day; what about a more instantaneous feedback mechanism?  I figure there are two sources for a measure of our productivity: Scrumworks and Subversion.  I decided that Subversion would provide a more immediate indicator of our progress than Scrumworks.  So I have a datasource, now I just needed a display mechanism.

I’ve been playing a lot lately with the Arduino and specifically with RGB LEDs. It’s super easy to communicate with the Arduino over its USB cable, so some of my first experiments with the RGB LEDs involved controlling them with Python. Now, the last time we were at Ikea I bought this weird little rubber lamp creature thing named Spöka.  It’s just two green LEDs inside with a rechargeable battery and some limited circuitry.  There’s actually room enough for an Arduino Pro Mini and the power cord appears to provide 4.8V so it would be perfect.  Of course, I don’t have a Pro Mini so for now I can prototype it with my Duemilanove.

Here’s the Spöka cover and the box I’ll be putting the Arduino/wiring in.  I cut a hole in the top to fit the little creature on to.

I’m really terrible at soldering but I did manage to get my RGB LED soldered onto a little board with some wires connected out.  Note: I actually ended up redoing this with a brighter LED I got from superbrightleds.com, I also soldered in a resistor.

The wiring is very simple, just the USB cable in and the few wires from the LED connected to the PWM pins on the Arduino.

The Arduino reads from the serial connection with one byte for the red, green, and blue LEDs.  There is a bit of fanciness with the red LED since it operates at a different voltage.  I’ve had some difficulty getting good color mixing with the red.  I imagine this could be resolved with wiring a different resistor for the red LED, but I haven’t tried that yet plus I’d need three resistors instead of one.  I’ve also added some “pulsating” action that makes the LEDs fade in and out a bit.  It’s especially cool with the color-mixing.

Here are some photos of the device in action.

Now we just need to connect this up to Subversion.  I used the pysvn and pyserial libraries.  Basically, the program monitors a local copy of a repo;  when it starts it gets all the commits that have occurred within the last three hours, then every 30 seconds it updates the repo and incorporates any new commits into the calculations.   To calculate the “productivity score” it sums up an exponential term decaying with time for each commit scaled by the “size” of the commit as determined by the length of its diff with the prevision revision.  It then uses this productivity score to set the colors on the Arduino: green is good, blue is okay, red is bad.

I’ve tried it out at the office and so far the response from the team has been really positive.  I’ve been playing a lot with the coefficients to get a nice effect from the system.  There are a number of factors to balance.  First, we want it to decay quickly enough that it provides good feedback but not so quickly that it’s too difficult to “keep it green.”  Also we want small commits to contribute a reasonable amount to the score but we want to ensure that large commits (for example adding a bunch of test data or something) don’t kick the score up so high that it stays green for hours.  There are still adjustments to be made but for now it works reasonably well; small to medium sized commits will keep the monster (this is the name that’s stuck) happy for about 20 to 30 minutes and pretty much after an hour and a half or two hours, it’s angry no matter what we’ve done.  With 3 or 4 people all working on a project we really shouldn’t go 2 hours without a commit and it’s not unreasonable to expect at least a small commit every 30 minutes.

There have been a few unanticpated benefits so far.  First, the system rewards more frequent commits even if they’re small.  This is a better practice in general, so that’s been nice.  This has encouraged more small refactoring work.  It’s more rewarding to make something like a small naming convention correction if you get some nice visual feedback.  Also, since it turns green (or at least blue) within 30 seconds of a commit, it’s a nice way to notify other team members that a commit has been made.  This leads to more frequent updating and fewer conflicts.  Finally, it can serve as an indicator that people aren’t sure what to do.  If the monster stays red for a while that’s a good time to get up, walk around and see what’s going on.

Since the color changes no matter who makes a commit, it is a team metric instead of a personal metric.  I think this is important for keeping it light-hearted and not something used to pressure people to feel like they have to be making commits every 30 minutes.  So far we haven’t had any problem with this but in the wrong hands or implemented poorly it could end up being something that would reduce morale instead of improving it.

Code is available on GitHub.  It’s not as clean as I’d like it to be, but it works well enough.