I was reminded of a post I made after visiting  Bletchley Park and the National Museum of Computing some years ago and realised it needed moving to my own blog. So here it is:

While visiting  Bletchley Park and the National Museum of Computing  I discovered some examples in history when pairing really worked.

The first example was in the “tunny room”. Messages from the German high command were transcribed here during World War II for processing in the decryption machines, after being intercepted at Knockholt. When a transmission was received on the incoming telegraph, it was transcribed onto tape feed by two operatives so that it could be fed into the machine. As the tour guide pointed out

“two girls were used for this, with the assumption being no two girls will make the same mistake”.

Reducing mistakes is one of the key benefits of pairing in software development teams, and prevents defects appearing later down stream. In the case of the Bletchley workers, the letters they were typing would have been Lorenzo code, a raw ciphertext received via headphones, so a misplaced letter could have thrown the decryption out completely, causing delays and misinformation.

The second pairing example was in the post war section of the museum, home to a restoration project for a 1950s punch card archiving system. The room, which does the work that a database might do today, is full of oily, complicated looking machinery. The first machine was the puncher. This was used to mark the cards with the data that needed storing – in the example at the museum, these were orders for a sales team. The pairing occurred here, at the point of data entry. Two operatives would have slightly different machines; one would punch a hole slightly above the number mark on the card, and one slightly below. A valid mark was therefore represented by an oval shape where the two punches intersected. A second machine, the verifier, was then used to ensure there were no errors on the cards. It detected single holes in the punch cards and flagged these as errors by outputting the values on a pink card. Cards that only had oval holes went onto the next stage. We still use pink cards on our Kanban wall to represent defects.

In this example the pairing was inherently built into the system through the mechanics of the machines involved and must have prevented a great deal of erroneous data getting through.

So, if pairing was so useful in during the war, and built into machines in the 50s, why isn’t it the de facto standard for software development today? Why hasn’t it simply grown in popularity since the 50s? I’d not heard of pair programming until I’d been working in the industry for 2 years, even having been at university for 3. There are many benefits to pairing in addition to the reduced defect rate, yet the practise doesn’t seem to have stuck around.

There does seem to be a resurgence of interest in pairing as agile software development gathers pace and I’m sure most of the luminaries of the agile world have been doing it for years. But why hasn’t it always been wide-spread?