A Slight Obsession with Build Monitors

A few years back I caught a couple of developers perusing the documentation for the CruiseControl continuous integration tool. It was a mainstay of our development environment. Their curiosity was piqued by an extension that integrated some home automation technology enabling mains power devices to be switched on and off. X-10 is low bandwidth power line protocol that has all but fallen off the map. Back then you could buy cheap X-10 devices by the bucket. Being an engineer at heart I had such a bucket and offered it up. So began a small obsession with build monitors.

After begging a developer to divert some energy to the configuration end, I prototyped a basic X-10 config setup. Most people were controlling cheap lava lamps at the time. The things would get hot and seemed like a bad idea. One of the other developers suggested that maybe I should look at flood lights. The idea was more fruitful than it first appeared.

Back in that day, moving to a new office was an adventure for  management. So much fun in fact, that they didn’t bothered to ask the teams what office design made the most sense. The particular gaff inflicted was to spread the development teams around an L-shape space. Any geographic separation of teams can be a challenge but I had not though such a small one to make much difference. However, with that small obstacle came separation into speciality focused groups and a corresponding drop in transparency. Where before there was eye contact now there was avoidance. A developer deep in thought could no longer be bothered with trying to see is someone “around the corner” was available.

Novelty and Transparency

During the move I finished my first build monitor, consisting of three floodlight fixtures mounted on a box. The goal was to shine the color of the build onto the ceiling. Red meant broken compile. Blue meant broken tests. Green for all was good in codeville. The ideal spot to place the monstrosity was none other than the elbow of the office L, pointing towards the ceiling so that all could see.

Novelty was guaranteed for a short while but what was odd was an immediate change in behavior. We were building greenfield financial banking application. As the product evolved there would be inevitable restructuring of the emergent architecture. The change at the base of the stack would ripple through the build, destabilizing it temporarily and causing teams to context switch to fix. With the flood lights came immediate feedback that physically isolated lava lamps could not give. Within a day developers stopped changing the stack without a preemptive email. The mere thought of being called out by a bat signal of shame had an immediate impact on build stability.

Steampunk Junk and the Arduino Build Monitor

Being dragged by one’s wife through a newest hardware warehouse while being expected to be inspired can be a drain on the fake smile. Unless they are selling hideous bathroom lamps at a discount. I spotted this thing. It was an ugly frosted five inch globe suspended by a rolled aluminum base. I imagined inverting it and mounting it on a wooden base with a couple of high powered Red-Green-Blue LEDs controlled by the hackers embedded controller of choice, the Arduino. Smile re-energized but my wife was left appalled at my taste in interior decoration.

I wanted to build from technology that anybody could use. Being tied to CruiseControl extensions was limiting. I chose to match the Arduino with Processing, a Java based environment intended to be accessible to non-developers.Typical users are artists and designers looking for tools for visualization and art installations. I used Processing to pull XML feeds from CruiseControl and radiate the result by communicating with the Arduino which handled the LED hardware. This has turned out to be a successful and extensible combination.

Where is this Whimsy Heading?

Building the monitor gave me a more personal connection to the work without interfering with it. My role as client PM and then development manager left me disconnected from the crafting of code. From these humble beginnings I have seen each evolution of my build monitors as an opportunity for greater play to be injected into the craft-like environment of software. Some results were expected but most like this first device have been unexpected. The display of light is too simple a summary of the complexity embedded in a large software development team. However the simplicity of this feedback indicator has only enticed me to deepen my obsession. Next time, the coming of the P.I.R.A.T.E.


About guywinterbotham

An Agile Buccaneer navigating the corporate storm
This entry was posted in Build Monitor, Play. Bookmark the permalink.

3 Responses to A Slight Obsession with Build Monitors

  1. Ryan Shriver says:

    Aha Guy, I remember those early days well. I recall with version 2 half the team being blinded the first time the red flood light went off! God, it was annoying when the build was broken, which was exactly the point 🙂

  2. Nice post. It got me thinking about creativity and building at work, even when it’s not officially part of your job anymore: http://www.nerdthoughts.net/2014/07/striking-chord-need-to-be-creative.html

  3. Pingback: Anatomy of a P.I.R.A.T.E. Build Monitor | The Agile Buccaneer

Leave a Message in this Bottle

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s