Osmotic communication – keeping the whole company in touch

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.

Two pizza teams

I’m at the Future of Web Apps Conference, London this week – there are some really interesting presentation, which I will post about over the next little while but to kick things off I wanted to talk a bit about Amazon’s ‘two pizza team‘ philosophy.

Pizza Man

Werner Vogels, Amazon’s CTO presented a paper on “Why and How Its Easier Than Ever Before To Build A Web Business and Compete With Anyone” – in which Werner discussed Amazon’s Web Services S3 (Simple Storage Service) and EC2 (Elastic Compute Cloud) – and how they can be leveraged by third parties (such as Smugmug, Second Life and YouOS.com) to build web apps at significantly reduced costs. The services look fantastic, I’ll write about them in more detail another time, but for now I want to discuss something that Werner mentioned in passing, in response to a question: Do Amazon developers use the Web Services?

It appears that they do. The Amazon development teams use the Web Services (such as S3 and EC2) to provide a framework on which to build products. What is interesting is that these project teams are small: if they can eat more than two pizzas, it’s too large (i.e. no more than 8 or 10 people).

The two pizza rule appears to me (Werner didn’t expand so I’m making the next bit up) to be a great way of making sure that a problem is broken down into small, bite size (sorry), chunks. This is a very good idea because:

  1. it means each multidisciplinary project team tackles a specific, well defined, business problem – they know what they are aiming for;
  2. the team is closer to the business owner or user – in big teams it is easy for team members to hide;
  3. the team can’t get too distracted nor over engineer the problem;
  4. the team should be more efficient because there should be a lower communication overhead – both within the team and between teams;
  5. it reduces complexity and therefore risk because the problem is partitioned;
  6. the team should have greater velocity and be able to iterate more rapidly;
  7. and finally if a project does go belly up it means the company hasn’t invested too much.

This approach to application development enables Amazon to be both relatively nimble in its application development and deploy an entirely new (i.e. non-core) service to a different market segment – helping it to diversify its offering. And there aren’t too many big enterprises that can say that.

Photo: Pizza Man, by Dickuhne. Used under licence.