The Artima Developer Community
Sponsored Link

Weblogs Forum
On Java Lava Lamps and Other eXtreme Feedback Devices

5 replies on 1 page. Most recent reply: Dec 9, 2005 6:47 AM by Alan Spencer

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Alberto Savoia

Posts: 95
Nickname: agitator
Registered: Aug, 2004

On Java Lava Lamps and Other eXtreme Feedback Devices (View in Weblogs)
Posted: Aug 26, 2004 5:30 PM
Reply to this message Reply
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.

A few months ago, on April 1(!) 2004 to be precise, I posted an article on eXtreme Feedback on

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

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

Have fun.



Posts: 4
Nickname: firefalcon
Registered: Apr, 2004

Re: On Java Lava Lamps and Other eXtreme Feedback Devices Posted: Aug 27, 2004 7:57 AM
Reply to this message Reply
This is really great things! I think I'll try one.

Celia Redmore

Posts: 21
Nickname: redmore
Registered: Jun, 2003

Re: On Java Lava Lamps and Other eXtreme Feedback Devices Posted: Aug 29, 2004 5:49 AM
Reply to this message Reply
Ooooh, I hate being condescended to. Treating technical staff as kindergartners is insulting and demeaning. Save the gimmicks for salespeople.

Alberto Savoia

Posts: 95
Nickname: agitator
Registered: Aug, 2004

Re: On Java Lava Lamps and Other eXtreme Feedback Devices Posted: Aug 31, 2004 10:42 AM
Reply to this message Reply

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.


Text from:

Mike Clark writes: "I got an opportunity to visit Alberto’s project a few weeks back and witness first-hand those infamous lava lamps. You really can’t miss them. When I walked in, the red lamp was bubbling. And yet the managers weren’t beating the programmers about the head and shoulders, as some might fear. Indeed, I didn’t 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 didn’t want to work on unstable ground.

It’s important to note that Alberto’s team is a bright group of folks building impressive products. Feedback is serious business, but they’ve 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, they’re confident that it won’t stay that way for long."

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: On Java Lava Lamps and Other eXtreme Feedback Devices Posted: Aug 31, 2004 4:40 PM
Reply to this message Reply
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.).

Alan Spencer

Posts: 1
Nickname: aspencer
Registered: Dec, 2005

Re: On Java Lava Lamps and Other eXtreme Feedback Devices Posted: Dec 9, 2005 6:47 AM
Reply to this message Reply
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 ;)

Flat View: This topic has 5 replies on 1 page
Topic: Collection versus Iterator Previous Topic   Next Topic Topic: Designing Programs to Accomodate Graphic Interfaces

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use