ego.istic.org

Last week I was talking with a colleague who plays guitar with a rock band. He told me (in hushed tones that suggested I should be shocked) that when his band played its first gig, they had never played together as a group before: although a few of them already knew each other, there were pairs who had never met; the band hadn't rehearsed together beforehand.

I thought back to my brass band experience so far. As a brass band is larger and has more than one player for most parts, it can afford to have a few extra members just show up for the gig, to pad out the band and give it more volume. Even though brass bands tend to play the same pieces (so that even the new or temporary players will have played them before), this is quite disruptive. The new players won't have seen how the conductor likes to interpret the piece in terms of balance and tempo changes. They won't be expecting the conductor to suddenly start beating in eight, or to do dynamics not written on the part. Because players realise their lack of experience, it makes them less confident, so they play more quietly. For these reasons, new players contribute far less to the band than the established members.

After considering this, I thought that in a small rock band, playing your first gig without having played together before must be quite exciting, even for experienced musicians. I was duly shocked, until it occurred to me that almost all software is developed in this way.

Typically, programming teams only meet when they start to design and write the real project—that is, when they start to perform. In larger companies, the same team can occasionally stay together from one project to the next, but in startups this is very rare. They don't get to rehearse together first, and they don't even get an opportunity before performing to find out what skills and expertise each member has—that is, what instruments they play. Surprisingly often, one or more participants will never have performed as part of a group before. If a musical ensemble got up on stage and only then realised they were lacking one or more crucial players, that would be an obvious organisational error, but for programming ensembles, it's accepted practice.

It sounds like a silly example precisely because it is almost unheard-of in the field of musical performance, but in commercial software development, it's very common. Often one member will have to learn a new instrument during the course of the performance, but it's not limited to programmers: sometimes the team will be lacking any QA, or any project management, as if the orchestra had got on stage and suddenly found they were without a conductor.

Little wonder, then, that so many software projects fail, and even the successful ones turn out to be unreliable. And all too often, this band of players who have not previously met finish the piece to find out they were playing to an empty hall all along. Investors get quite unhappy when this happens.

Even among top musicians, the folk wisdom suggests that an error rate of up to 3% is to be expected. (Finney and Palmer 2003 gives 2.8% mean for experienced musicians on rehearsed individual phrases and says this is “low”.) Laeng and Park 1998 suggests that you can expect this to increase to 10-15% for sight-reading even of simple pieces. So when you introduce additional sources of error by expecting people who have never met to work in a synchronised fashion and to produce a well-balanced sound regardless of what mix of instruments they have, you shouldn't be surprised that the performance is far from seamless.

It's easy to say that writing software is not like performing music, and indeed, on the surface they are quite dissimilar. But the synchronisation between participants, the freedom to interpret the given requirements, the strict time constraints, the way any one player can let the whole team down, and the dependence of the continued existence of the team upon a successful outcome; all these things are common to both endeavours.

So, from my colleague's anecdote, I learned that it's important to give your programming team time and space to rehearse, to have some practice runs. Prototypes, and toy or side projects, like rehearsals, allow the participants to learn the balance of the ensemble, to work out each others' strengths and weaknesses, to find areas of the piece they keep getting wrong, and to agree on a common interpretation. Orchestras and bands will always have a rehearsal: if you don't allow them one, you will find that the performance becomes it. In the same way, programmers will always write a prototype, and if you don't allow for this you will end up releasing it to customers.