This is a free translation and revision of an earlier article written in german.
Since March 2007, the Schneide uses another Extreme Feedback Device (XFD): the Code Flow-O-Meter.
So what is this thing?
We bought a portable fountain made of slate, filled in water (no additives) and connected the power supply cord with a X10 application module. Then we programmed a litte IRC Bot (using the ten-minutes-to-success java IRC library pircbot) that triggers the module. We were then able to control the fountain by speaking to it over IRC.
Afterwards, we piped the commit messages of our source repositories to a little script that determines the “impact” of the commit by measuring the amount of changes to the code. This sounds more sophisticated as it really is, the number of changed files was a good enough guess for it. This impact is related to a duration, the more impact, the longer the timespan. Now the script tells the IRC bot to activate the fountain for that amount of time.
This way, we have a direct but unobtrusive notification about what is going on in the repositories, as this is the most important location of our company (talking about the numerous safety nets we applied to it would require another blog post). Initially, we thought about playing an audio sample singing “alleluia”, too, but this became ridiculous soon.
But why do you want this notification?
One of the rules of agile (or good) programming says “commit early, commit often”. But as soon as every little commit gets examined by a continuous integration server, all automated tests and a large number of software quality metric tools, the liability to keep the changes local a little bit longer grows. “After all, it’s ready when it’s done, and this is soon enough to check in” was a common justification especially among the less experienced programmers. But that’s the best way to miss the early feedback. And early feedback is effective feedback.
So we installed our portable fountain as a counter-incentive against late commits and started a little game. The rule of the game is simple:
Keep the Flow-O-Meter running!
When you commit, the fountain flows. The size of your commit is not as important as the commit itself, so its better to commit often. If everyone does it, the fountain may flow the whole day.
The Code Flow-O-Meter may be regarded as a measurement device of “progress”. Things are in a state of flux as long as it is running.
And did it work?
Yes, definitly. The Code Flow-O-Meter has become our little pet. Everyone loves it because it’s friendly and comforting. Think of a tamagochi, but without the annoyances. You only need to change and commit something to feed it and get the reward, nothing more.
As an additional gain, everybody else loves it, too. When we show it to a customer, they first see an ordinary portable fountain. When we explain and demonstrate our working cycle (code, commit, review) to them, something magical happens. I tend to think they involuntary get the notion of something happening after the commit when the fountain comes to life. This may be the concept of a build server, otherwise being invisible and intangible, materializing in the fountain. When we continue to explain what happens after the build, like the ONOZ! lamp lighting up to indicate a failed build, it’s already clear to them that the process does not end with the waterflow. The Code Flow-O-Meter serves as a link between the developer’s local work and the build feedback arriving out of nowhere some minutes later.
Read more about our Extreme Feedback Devices:
Schneide Blog 
7 thoughts on “Extreme Feedback Device (XFD): The Code Flow-O-Meter”