Last weekend I was chatting with my Dad about his current work project, and our conversation led me to start thinking about pair programming and pairing in general.
The idea of pair programming was popularised from the early days of eXtreme Programming or XP. The book Extreme Programming Explained written by Kent Beck describes pair programming as:
“Writing all production programs with two people sitting at one machine … and is a dialog between two people simultaneously programming (and analysing and designing and testing) and trying to program better.”
My Dad was telling me that the majority of the work that he does is done in pairs. My Dad however, is not a programmer; he’s a carpenter, and has been so for the last 40 years. According to my dad, pairing has been common practice on the projects he has worked on for the majority of his career.
“The reason why we work in pairs is so that we know that the work that we produce at the end of it is of a higher quality than if we had done it individually, and that is because we can more easily work out the best solution as a pair, as two heads are better than one. We can also pull each other up if we feel like our work is slipping”
“It also means that when the foreman comes to check our work there is less opportunity for him to find any snagging, and it means that we then don’t have to go back and re-do something therefore saving time in the long run, and because of that we get less earache from the foreman”
Of course not all the work my Dad does requires pairing. Something trivial (trivial to a skilled carpenter like my Dad of course) like fitting a skirting does not require pairing, but creating a replica jumbo jet out of wood (his most recent project), most certainly does require pairing. My Dad went on to say:
“In most projects, we all start off in pairs as default, and then we decide on a case by case basis whether we actually need to pair on things, but we mostly do as we know we work better that way”
He also said that he wouldn’t be the carpenter he is today if he hadn’t had the opportunity to work in pairs. He feels that it allowed him to learn his craft more quickly and has continually driven him to create better and better work. He finally went on to say:
“Working in different pairs not only helps us to create better work, it allows us to come together as a team and learn from each other”
The benefits that my Dad has spoken about are very similar to the success stories and benefits developers speak about when they practice pair programming. It therefore seems strange that some organisations still resist against people developing software in pairs.
My Dad’s example also goes to show that pairing is not just appropriate for coding. Could there be opportunities to pair up for other roles in our teams. Pair Scrum Mastering anyone?
In my opinion, the benefits of pairing outweigh any perceived negatives. If it is a means to delivering better quality work and increased learning, then it should be encouraged in all appropriate situations, including those in non-programming situations.
It would be great to hear your experiences of pairing whether it be in programming or a completely different role or situation.
Image credit: Luis Brito