Many developers that I’ve worked with seem to have an almost unhealthy obsession with the idea of “Information Radiators”- wall-mounted screens, coloured lights and displays in the office, showing successful or failing builds and deployments as well as general information about the system.
At first this may seem a little dramatic – isn’t it humiliating to have your failures publicized? Why does anyone else but you care whether your build fails? What benefits does this sort of thing give us?
Admittedly it can be a little embarrassing to start with to have your mistakes broadcast across the team, but let’s be honest everyone checks in builds that fail from time to time. If your builds keep failing maybe you or your colleagues need to pay more attention to merging your changes, or maybe you need to run compilations and unit tests locally before you submit your changes. With time the flashing lights and screens will become useful progress indicators rather than a potential source of embarrassment.
If you’re not sure why the rest of the team need to know that a build has failed in some way, wait until you merge non-building code into your changes. When your build starts to fail and you spend time searching for the problem only to find someone else’s changes broke it, all will become clear.
There are of course other ways of alerting people about problems, but the (slightly pessimistic) chart below shows the problems with them:
Alert Method | What Happens In The Real World |
|---|---|
Display a failure message on a screen or web page | Nobody looks |
Email a failure message | Mail is conveniently routed to a folder somewhere |
Display failure message in an Instant Messenger | People ignore or mute it |
Add failure to RSS feed | Nobody subscribes to the RSS feed |
On the other hand other industries from stock traders to fast food restaurants have already found that flashing red displays get attention very effectively.
That covers HOW to get people’s attention, but it doesn’t cover why they should care.
One of the biggest problems you encounter with big projects is getting an accurate measure of their progress. What often happens with waterfall development is that the Project Manager regularly asks how complete the task a developer is working on is. The developer might guess at 50%, and then the PM treats this as some sort of initial bargaining position, suggesting that the task might “really” be “60 or 70% complete, so can we round that to 80%?”. Most developers faced with a PM, possibly in front of the rest of the team, are not going to say “No, I mean 50%,”. Those that do often find themselves described as “Uncooperative” or “Unhelpful” with predictable results for their jobs when the inevitable redundancies come around.
Agile’s focus on purely whether tasks are not started, in progress or done gives a much more accurate picture of the progress of the project, Nobody can say something is ready when it’s not building, when tests are failing, or if it’s not even showing on any displays.
This is where the real benefits in information radiators lie. More so if you have a large project; there are always some things that tend to fall through the cracks, remaining unnoticed until you actually have to deploy them. Adding information radiators to the development vastly reduces the chances of this happening. Connecting them to the build system eliminates any human interaction with their source data, eliminating the main cause of inaccuracy: people. You end up with a system that shows exactly what is going on, and what isn’t, with no chance of anyone saying, for whatever reason, that they’ve completed something when they haven’t. If a component has been omitted it can be added to the process as soon as this is spotted, and its progress will be tracked along with everything else. The development velocities, test coverage, story completion and system completion statistics are automatically and accurately reported.
Like any other automation this will take effort in the early stages of the project. The benefits are vastly increased accuracy and visibility of your project’s progress. It also reduces the likelihood of you discovering part way through a huge deployment* that something everyone thought was ready actually wasn't, and now you have to decide whether to roll back or find some other way of handling the problem.
* - Of course you would know before the ACTUAL day of the deployment that something was missing, because you would have rehearsed the deployment at least once, because you’re a professional. If this is a new thing to you, and you don't want the pain of failed deployments (you really don't!) take a look at Eliminating Failed Deployments – Part 1 – Replication! Complication? Automation! - The Other RCA! and Eliminating Failed Deployments – Part 2 – Automate Your Obsession to start...
