Silent Pair Programming – Review

On Thursday evening, the London Software Craftsmanship Community organised a Halloween treat – a silent pair programming session – at the Google Campus. A colleague of mine and I decided that we talk too much during the day and so a silent programming challenge might be quite appropriate.

I had not been to the campus before, but it is a very interesting complex. It’s clearly made to be hip, yet minimalistic and function in style. The intended audience is very clearly geeks with lots of power sockets to plug your machines in as well as nice and fast Wifi. There was also the tell-tale smell of cheesy-Pizza-Goodness, which I thought was a little cliché.

Before the start of the session, Sandro talked a bit about Global Day of Code Retreat which sounded pretty awesome and I’ll definitely try to sign up for it:

A code retreat is a day that you spend solving a programming problem (traditionally Conway’s Game Of Life). The day is split into six sessions each lasting 45 minutes of pair programming in a TDD fashion. After each session, you delete all of the code you have written and swap pairs for the next session. There is also time for a quick retrospective between sessions to share experiences. Gradually, the facilitator may introduce additional constraints to the sessions. A good, more detailed description of the structure can be found here.

I think it’ll be really fascinating to see how good solutions will disseminate through the group with this kind of setup. It could also be extremely useful as a hands-on training/collaboration session for a group of developers to remind people of coding standards or introduce new concepts to the team.

Now – let’s talk about the session itself.

The format of the session itself was to program a particular problem together with another pair in a ping pong fashion. The problem Frankie proposed for the evening was the Harry Potter kata. Ping pong programming works as follows:

Dev A writes a test and passes the keyboard to dev B.
Dev B makes the test pass and writes a new test, passing the keyboard back to dev A.
Repeat until you can’t think of any more tests.

This is a fairly well established practice and is for example described in the apprenticeship patterns book I reviewed earlier.

The twist for the night was that it was supposed to be a silent ping pong session: This means no communication about the code – no talking, no cheating with notepad, no comments in the code, no scribbling or upfront design. (Communication about other things – the weather, coffee or the IDE are fine though.) The goal is for the code itself to be clear enough to enable the next person to continue on without any additional information. If the code is not clear enough, then you say “I’m very sorry, but I’m stuck and not sure what to do” and pass the keyboard back. After you have made the test pass, you are also allowed to refactor as much as necessary.

Every 25 minutes, we then had a quick retro to discuss how things were going.

For me, this was a very interesting evening and I think I learnt a lot about incremental code & test design. I also realised that some of the code I think is clear is really anything but. Ping pong programming also made TDD and pair programming feel extremely natural.