At the FOWA conference Matt and Anil, from Last.FM spoke about their use of IRC as an internal communication channel to improve their comms across the whole company.

For those that aren’t familiar with IRC its short for Internet Relay Chat and is a real-time Internet chat protocol designed for group (many-to-many) communication.

One of the things that is interesting about IRC is that it supports automated clients or bots that can be used (queried) to provide specific information via the chat window. So for example, at Last.FM they have a bot called IRCcat (now released under an open source license) that posts to the IRC channel when stuff happens within the development environment – so for example when code is committed to Subversion or a bug closed in Trac these events becomes part of the chat conversation; or it can be used to hand off commands from IRC to another program such as a shell script.

Because everyone at Last.FM has IRC running everyone is aware of what is happening across the company. For example, everyone knows when a bug is fixed, when a new one is entered, when the application throws an exception, or when new code is committed; it also means you can ask the whole company a question, their opinion, let them know the latest news.

This doesn’t (or shouldn’t) mean that all communication is carried out online but it does mean that everyone can keep up-to-date with very little overhead and that this happens passively, by osmosis, rather than relying on a separate (active) reporting process. This is of course good because it means people can focus on their job and data flows out as a by-product; it also means that there’s less (possibly no) opportunity for someone to fudge the data – to hide what is really happening, it’s all out there and transparent.

Now my understanding is that the Last.FM folk’s IRCcat use is restricted to reporting on code and tickets via Subversion and Trac (apologies if I’m wrong).

At SPA Dave Thomas outlined an interesting idea – version everything. Put backlogs, risk and issue logs, time estimates, burn-down charts all into your configuration management tools. Use a wiki or IDE to enter data (tied into your configuration management tools) and tie this into the code (ref); and use the data to automatically generate project reports. The benefits are again obvious: transparency and automation of project reporting. If someone decided to reprioritise the product backlog or reassign work everyone knows when it happened and who did it, and everyone has access to the burn-down charts so everyone knows if the project is on target or not.

I think it would be really interesting to tie these two ideas together: store all your project artefacts in your configuration management tools (entered via a wiki and/or IDE) and automatically generate reports from it; but also provide a live, real-time commentary on the project by hooking in IRC.

Photo: Communications, by assbach. Used under licence.