Homebrew build status traffic light

Have you ever used build light indicator  (a light, software utility or sound emitter) to inform the team about the current status of the build?  Our team found using one of these, in conjunction with continuous integration and automated testing,  to be a great help towards achieving 98% build stability.  I have a little hobby/side-project going to build a better one starting with a $30 toy traffic light (see picture) and embedding some Arduino electronics that will allow it to be easily setup and used.

What the lights mean:

• Green means the build is working
• Red means that it is broken
• Yellow means whatever you want.  The server is building or a test has failed, but we're giving you X minutes to fix it before the status goes to red.

I'll open source the hardware and software.  I might even sell a few at cost while I'm having fun making them.

Currently, the interface is an ethernet connection that uses DNS & DHCP to plug into your current network with little setup required.  The traffic light will appear as a server that accepts simple commands that change its state.  An optional audio cue will sound indicating a status change.

Potential future features:

• Data logging the events and overall build stability metrics
• Server page statistics (graph of stability, etc).
• Simple display for setup options.

Please send suggestions about what you'd like such device like this to do and how you would like to interface it to your build server software.

Accountability vs. Responsibility

[Cross-posted from Gamasutra]



I read this great quote from Gabe Newell in this Gamasutra article:
“Yeah, nobody can ever say "that's not my job." Nobody ever gets to let themselves off the hook. If there's a problem, you've gotta fix it.”

It demonstrates a high level of accountability at Valve, not just responsibility. The words accountability and responsibility are used interchangeably, but they don’t mean the same thing and the difference is important for game development teams.

Responsibility is assignable and forward looking.  For example, as an artist, I might be responsible for creating a model.  As a programmer, I might be responsible for making the character jump.

Accountability is backward looking.  Both the artist and programmer should be accountable for the character correctly jumping over the model.  Unfortunately, a lack of accountability might lead both to ignore the problem as “not their responsibility”.

Accountability isn’t as easily assignable as responsibility.  It’s more intrinsic.

Focusing exclusively on the assignment of responsibility tends to tell developers that those making the assignments will take care of all the cracks that will happen between areas of responsibility.  A balanced approached of delivering a part of a game and being accountable for its fun of it is harder.

The hard part is how is to grow accountability in a studio culture.  How do you grow it in yours?