Pairing in History
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?
Paul Shannon - Agile Software Development 
>>> why isn’t it the de facto standard for software development today?
Expensive – most software does not warrant spending two salaries on each line of code. Automated tests, regular discussions, etc. lead to good enough code for most requirements.
Stifles creativity in individuals, because one or both of the pair feel pressured in the presence of someone else. Sometimes this lowers productivity, but worse it can prevent some individuals reaching their potential. I know many excellent developers who would hate a paired environments.
While I wouldn’t normally respond to an anonymous commenter I feel this person’s need to post such a comment under veiled anonymity goes some way to answer my question of why pair programming is not the de facto standard. It appears that the rumour and belief that pairing means you waste the time of the extra person on a task because the first person could have completed it on their own is perpetuated without real evidence or experience. I disagree with this belief, and furthermore, have evidence to prove that it does work. Just the two organisations I’ve worked in have improved their cycle times and throughput by adopting pair programming – the most noticeable metric that helps this is the reduction in defect rates. Pairing reduces defects because the discussion and consensus on design and strategy mean that potential bugs are spotted and reduced earlier. The second pair of eyes, on a fundamental level, stops simple mistakes too. When the code is released, if a defect does arise, any member of the team can help fix the defect as pairing promotes knowledge sharing, so issues can be resolved quickly, and the team can then concentrate on provide more business value.
I’ve seen evidence in both camps to the stifling of creativity when pairing, but my own experience suggests that pairing increases the innovation through diversity. Our team comprises people of different backgrounds (culturally and technically), along with people of different ages and experience; it’s this diversity that means we can create a “best of breed” solution. Pair programming means that every task gets some diversity, with ideas of the driver and navigator coming to the fore. Having to justify your decisions while pairing means you have to think constructively about your own ideas, and sharing them improves your creativity by “bouncing them” off your partner. If someone thinks they can sit down on their own and come up with better ideas then when sharing with someone else I’d say they are misguided or just arrogant.
I have spoken to people about their concerns around pair programming and I always advise them to give it a try before making assumptions. I only hope my concerned reader here has had some experience in pair programming before deciding it not for them. It isn’t for everyone, but from the people I’ve spoken to I find those that don’t like it are usually the exception, which leads me to ask the question again, why is it not more mainstream?