I have recently had the opportunity to work in an organisation that actively supports agile practices, including pairing. Let’s start with a definition:
All code to be sent into production is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project. http://www.extremeprogramming.org/rules/pair.html
I’ll come back to that. First my personal experiences.
I was willing to give pairing a fair go. I am a firm believer that a jewel is greater than the sum of it’s facets
The first few weeks were tiring. Pairing while learning a new environment is exhausting. You would think this would lead to faster saturation learning, but I am not convinced I ‘got it’ any faster that before when learning for myself.
Our team includes a good variety in educational, cultural and technical backgrounds.
When working with another experienced (read older) professional, pairing is like the worst of back-seat driving and design-by-committee. Due to the former (including dozing in the back seat), quality is very little higher than either one alone. And the latter means that two people are creating less than either one alone. In short – thumbs down on pairing in this situation.
How about cross-discipline? Well I have had a configuration and database expert so bored while I needed to update some code that they resorted to making paper air-planes.
I have to learn to do shorter posts more often otherwise they never get completed. So, in conclusion:
- Pairing is good for knowledge transfer with one lead, one follower. Let the learner drive.
- Pairing with separate machines is good for cross-discipline tasks with the pair working together and separately as the task warrants.
- Pairing is inefficient with two experienced professionals. The result is design by committee.
- Pairing does not reduce bug introduction with experienced people. The tendency is to trust the partner who is driving.