Summary
eXtreme Feedback Devices (XFDs) are a fun and effective way to help your entire development team to know about and pay attention to the project status and metrics you care about.
The article was on a relatively serious subject: "How do you get your team to pay attention to the software/project status and metrics that you care about?", but one of my solutions for getting the team to pay attention was to "invent" and implement eXtreme Feedback Devices (XFDs) that would be very visible, fun, and hard to ignore.
One of these XFDs consists of a pair of Lava lamps (one green and one red) remotely connected to our build and test system in such a way that a successful build (all tests pass) turns on the green lava lamp, and a failed build (or failed tests) turns on the red one.
The original Java Lava Lamps have been glowing red and green for the past several months in our offices, and have achieved something of a cult status (e.g. they are included in Mike Clark's excellent book Pragmatic Project Automation, and have recently received a fair amount of buzz on Slashdot.com.)
The interesting thing, for me, is that something that I started as something of a joke (it was April 1st after all) actually turned out to be a very useful tool in more ways than one. Sure, I could go to our CruiseControl page to see if they build is broken, or set-up email alerts, but keeping track of the lamps (which are centrally located in our development area) is easier, faster, and gives me an ongoing view into the current status and ebb-and-flow of our build and test cycles.
If you are amused by the idea of the Java Lava Lamp and would like to build your own, you are in luck. Mike Clark just posted instructions, HW requirements, and links to the software you need on http://www.pragmaticprogrammer.com/pa/pa.html.
I can understand your position and concern, but the key is in how the idea of eXtreme Feedback is presented, interpreted, and used. Below is a note from a recent visit by Mike Clark - as you can see, in our case there is nothing condescending, or insulting, or demeaning.
Mike Clark writes: "I got an opportunity to visit Albertos project a few weeks back and witness first-hand those infamous lava lamps. You really cant miss them. When I walked in, the red lamp was bubbling. And yet the managers werent beating the programmers about the head and shoulders, as some might fear. Indeed, I didnt sense any sort of panic. What I did sense was confidence.
See, the team had learned to take the red lamp as feedback. They run an extensive battery of tests on every build and the red lamp was telling them that their tests were actually testing something. An assertion somewhere had failed the last time somebody checked in code. This is a good thing. Indeed, this is what continuous integration is all about. It becomes a bad thing when the green lamp never turns on. So they were diligently (and confidently) working to repair the build as a priority over other tasks for the day because they didnt want to work on unstable ground.
Its important to note that Albertos team is a bright group of folks building impressive products. Feedback is serious business, but theyve found a way to make it fun. They use the lava lamps to their advantage, not as gimmicks or another way for the pointy-haired manager to keep tabs on their work. And when the lamp does go red, theyre confident that it wont stay that way for long."
When I worked at SPC (Software Publishing Corporation) almost a decade-and-a-half ago we had the build for Harvard Graphics automated and wired up to call a phone number when it failed. I think it was a pager for the unlucky person who was responsible for the build: in the days when the build took all night long, that meant a wake up call. Microsoft probably still has such things, but I've not worked on a project that takes all night long to compile in years, I'm happy to say.
Another thing a clever fellow there came up with was a very nifty system for unit testing (I don't remember if that was the terminology used at the time, though), built with lex & yacc that allowed you to ineractively script your C/C++ code and test your APIs (kind of an approximation of what you could do today with Python, Ruby, Jython, etc.).
Hi, I'm not sure if this is an XFD exactly, maybe a broud definition of the "D". But we have built a very simple module on top of cruise that, depending on the result of a build, plays a short audio sample. We have the luxury of being sound removed from people that don't want to hear it.
It is great to use another sense to get feedback, but if you do this pick your samples carefully and get lots, you can get sick of bad ones quickly ;)
Previous Topic
