With Agile and Continuous Integration becoming popular, a significant number of development teams are using information radiators – mostly focussed on showing the latest build status. Information radiators are a very powerful way to aid communication and subtly adjust a team’s behaviour and attitude. The catch however is that it can be quite hard to control how you subtly adjust the team’s attitude because the pressure to change is so subtle.

Probably the best example of information radiators working against the team is displaying build status when the build almost always fails. Since the screen is continuously red it quickly desensitises the team and actually encourages them to ignore test failures – exactly the opposite to the desired behaviour.

The key to making information radiators work is to think long and hard about everything that is and isn’t displayed there in great detail – positioning, font size, colour, groupings and relations all impact the information that is being radiated. For example, if the aim is to encourage the team to quickly notice and fix test failures and tests that fail are marked in red, then it’s vital that any information on that radiator which is red is something the team should treat as top priority to fix. If it’s not the same priority as a broken test then put it on a different radiator or make it a different colour.

If you’re suffering with a lot of intermittent test failures, focus on the number of failures rather than just showing a red screen constantly. Displaying the number of failures in a font size that increases with the number of failing tests can add a useful distinction. As the intermittency is reduced, increase the rate that the font size ramps up – that way a “bad” test run stays roughly the same font size.

Another common mistake is to boldly display failures for nightly runs all day long. Information that only changes once a day shouldn’t be permanently on a radiator – use email, IM or other methods to keep people informed of the status. Another option is to bundle up a group of things that are concerning when they fail but can’t be fixed quickly for whatever reason and group them together on one display. That way they are separated from the “fix this now” type of things like unit tests and are less likely to desensitise the team.

Finally, make sure you carefully chose the type of visualisation. Red/green works well for things that are absolute – either passing or failing, but it can’t show trends. Graphs can be powerful to show trends over type but aren’t as good at highlighting wether or not the current value is in a range. For showing ranges or magnitude, consider using gauges etc. There are plenty of other types of visualisations that are useful in different situations so make sure the one you pick is suitable for the type of data you’re visualising.

With a little bit of careful thought and planning, combined with ongoing tweaking and improvement information radiators can dramatically improve the effectiveness of your team and push them towards the right kind of habits. Used correctly, they are one of the most important tools in software development.

Robert Burrell Donkin:

ThoughtWorks are opening their new office right in the center of Manchester with a conference. The cost is £75 and places limited to 50.

I'm particularly looking forward to Dave Farley on continuous delivery…

It’s nice to read things like this and be able to think – meh, I already have to listen to him everyday at work. :) Basically, I’m really enjoying constantly having the feeling that I’m the dumbest person in the room because there’s always a ton of learning that comes out of that experience.

Perhaps the only thing better than that feeling is also knowing that I’m free to argue my case, against anyone (even if they have literally written the book) if I feel the team isn’t heading in the optimal direction and have those arguments heard and considered. Occasionally I’m even right.

The current competition in the smart phone space between Android and iPhone is both fascinating to watch and provides for some quite vigorous and entertaining debates. I find one pair of arguments particularly entertaining:

1. Apple is abusing their monopoly with iPhone
2. Android has more market share than iPhone and is selling at a faster rate

It’s interesting how often the same person will attempt to leverage both of these arguments (or likely better worded variants thereof) without ever realising that by definition, they can’t both be true. If Android is outselling iPhone, then it would be impossible for Apple to have a monopoly and thus can’t abuse it1.

In fact, out of Apple and Google, the one company that does have a monopoly is actually Google – in search. This in itself isn’t an issue however. They acquired the monopoly through better innovation and execution and there’s no real argument to suggest that they are abusing that monopoly to artificially raise prices or extend into other markets2.

What most people are trying to claim when they refer to Apple’s “monopoly” is that Apple has a monopoly on iPhones. However, that’s not a monopoly, that’s a product and a trademark. If you truly believe that a company which doesn’t OEM all it’s products is evil you will find yourself boycotting the vast majority of companies in all areas of life. That simply isn’t what a monopoly is and making such claims simply undermines your argument.

1 – this is different to not likely Apple because they’re not open source or not liking their policies, I’m specifically referring to the claim of monopolistic abuse↩

2 – on the other hand they seem to try to use GMail to extend into new markets a lot. Just not particularly successfully and I don’t think it would be reasonable to suggest that they have a monopoly even of free webmail provides let alone over email in general. ↩

One of the things I really enjoy about the software development teams I’ve worked with is their relentless focus on improving their overall productivity – producing more business value in less time and with less cost each every iteration. It’s largely this drive for productivity that drives developers to focus on quality – buggy code is hard to maintain and delivers little or no business value. Similarly it makes developers really care about the tools they use – the programming language, the OS, the IDE or editor, continuous integration, source control and all the other tools or systems they have to work with. When it comes to tools, nothing is ever good enough and we always want more. So long as that desire for perfection is balanced by careful, realistic prioritization it’s a fantastic thing to have in a team.

However, there’s one very common blind spot in this drive for perfection – in the tools we write for ourselves. It’s quite common for a team to decide that a third party tool simply isn’t good enough for them and is hampering their productivity so they should write their own, better version. The new tool quickly comes together and starts showing how much better it is than the old tool in the identified areas of weakness and everything is wonderful and rosy. Except of course, that it isn’t.

What teams generally miss is all the ways that the original tool was wonderful and polished, and the new tool is seriously lacking. For some reason we have to be a lot more pragmatic about the tools we build than about the tools we buy. There’s no good reason for this, our homegrown tools should be not just a little better, but a lot better, indisputably better than what they replace. If they aren’t then we’ve wasted a lot of precious time developing a tool that would have been better invested elsewhere. Solving the problems of the old tool is not a productivity gain if you fail to replicate the good things about it as well.

The common attribute among the best tools, that really provide measurable productivity boosts, is a relentless attention to detail. UI is the most common area that people think of when sweating the details, but this isn’t about having a perfect looking UI – it’s about making it quick and easy to use the tool for what it’s supposed to do. The real purpose, not just the first purpose you think of. For example, a continuous integration server isn’t about regularly running builds – it’s about making it easy to see when and why something broke in the software.

Similarly a build tool isn’t just about building your software. It’s also about creating static code analysis reports, running unit tests and probably interacting with a number of other systems – it may even start and stop the system during development. The scope is generally so much wider than just the basics of compiling code and dumping it into a JAR or ZIP file. That extra scope affects the trade-offs you should make in choosing your build tool. Maybe it’s not so important to make it build a trivial project just using all default settings. Maybe the scope is now so broad that building your own tool is more work than it could possibly be of benefit.

Ultimately, developers like to believe that any problem is quick and easy to solve. It’s the details that kill though – either because they’re missing and the tool doesn’t deliver productivity improvements or because they dramatically increase the effort required to build the tool, eliminating any potential return on investment. So when you’re next considering building your own version of some tool, first stop and think about all the little details that are required and make sure you really sweat them if you still decide to go forward. You may suddenly find you’re better off getting involved with the development of an existing tool and improving it rather than starting again from scratch.