Response Article: Pair Program & Remain on Friendly Terms

This is a response article to “Pair Programming: Will It Make You Hate Your Colleagues?” blog post. The author of this article argues that pair programming 100% of the coding time is not a good idea and would result in annoyance between the programmers. I would like to disagree with the arguments made and argue that it is a perfectly good programming principle that can be applied everyday while the programmers still remaining on friendly terms.

Two thinking heads are always better than one

The author argues that every project has  “mundane” and “trivial” code to write, hence pair programming in such a case is a waste of time and talent, as one of the programmers could do the job well. To the contrary, I believe that when solving “obvious” tasks, pair programming is extremely beneficial. This is because, when programming alone people tend to make mistakes when they least expect them as they become too confident with the simple tasks and make careless mistakes. In the case of pair programming, solving these tasks may be boring and seem as a waste of time, however they are effective in catching bugs and with two people coding them up the opportunity to try out different approaches even to mundane tasks still remains[1]. Hence, the initial boredom should lead to more less discontent after, as mistakes are avoided early on.

Taking the time to learn

One more point that is being made that pair programming does not allow the observer (the developer that observes the person that codes) to learn how to use the developers tools. However, I think that this is not the case with pair programming as it has educational aims. In pair programming there are three types of pairs: novice-novice, novice-expert & expert-expert. In any situation one can take time to learn as an input to the future. The person has their hands on coding (the so called driver) uses the tool, while the observer observes carefully what is being done and then the roles should be switched in order to share the experience. Of course, this would take more time as two people would have to go through similar steps, but it is an input to the future and both developers learn how to use the tool. In the case of novice-expert pair, the expert can become the observer and advise the novice how to use the tool while they drive. Such an environment should not result in irritation, it should cause gratitude and joy that something new has been learnt [2].

No superiority & avoiding conflict

It was argued that disagreements on design and implementation may result in one of the team members to feel undervalued. Of course, an argument may happen, but if there is a mutual understanding that all choices have to be justified, then the decision with better reasoning is made no matter who suggested it. As both developers are to aim for the best solution “giving in” in order to avoid conflict does not seem reasonable, because one will have to live with decisions made for a long time. Hence, there is no programmer is superior [3] unless it is the expert-novice situation, where the expert usually is the one to make the big decisions, but should also be open to hearing the opinion of the novice, who may point out something that has been missed. Therefore, of course it may be disappointing that maybe one programmer’s decisions prove to be more justified more often, but the other programmer can learn from it and in the future they may follow a similar line of reasoning or may find better arguments to refute it, hence being grateful for improvement.

 Spending time exploring 

With regards to the idea that pair programming reduces one’s individual familiarity with the code base, it can be said that such a situation should not exist, otherwise the whole project is in jeopardy. This is because both developers should be familiar with the whole code base and be aware of all the changes that are being made while pair programming and understand them in order to make good development decisions in the future. Collectively exploring the code should cause more satisfaction than anything else and make the programmers more confident with their understanding [4], as collaborative exploration should bring out aspects of the code that one would not notice alone and should make understanding the code easier, as different people understand different things.

 Being considerate

The argument that programmers have days of low productivity that are not good for pair programming and may result in conflict and have extremely productive longer days that compensate for the former cannot be applicable in a well functioning working environment. This is because, work has to be done and one cannot wait until the morning of or plan the way that they will feel during that particular day. Of course, everyone has good and bad days, with this understanding within the pair of programmers, adjustments can be done to who is “driving” and “observing”. It is understandable that everyone is different and may get irritated or otherwise, but the assumption is that two reasonable individuals are coding a solution up and have no other option but to get the work done. Since everyone is human, one should support the other on the bad days and not to expect the other to catch up during the extremely good days, with such a mutual understanding and respect, colleagues would respect each other rather than risk hatred.

 Conclusion

All in all, I believe that taking the pair programming approach every single time when coding is a practical technique and will not cause the programmers in pairs to hate each other. The idea is that two people approaching a problem is always better than one, as it reduces the amount of mistakes made and ensures that in the future there will be less problems. Pair programming is based on mutual respect and consideration of others’ opinion, which provides confidence in the solutions implemented and provides many opportunities to learn. When working this close together and relying on each others decision it is difficult not to remain on friendly terms as trust develops over time.

 References:

[1] Dominic Williams: Don’t restrict pair programming to difficult tasks, http://www.dominicwilliams.net/en/pair_diff.html

[2]Cockburn, Alistair; Williams, Laurie (2000). “The Costs and Benefits of Pair Programming” . Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).

[3] Pair Programming wiki,  http://c2.com/cgi/wiki?PairProgrammingQuestions

[4] Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries. “Strengthening the Case for Pair Programming.” IEEE Software. IEEE Software, July–Aug. 2000. Web. 4 October 2013