Two in the hand is better than one in the bush

Every couple of months or years, people from our industry, try to find better ways of creating products with better quality and faster turnaround. One such initiative is the Extreme Programming methodology or XP as it is more commonly called. XP lays down couple of best practices that are proven to enhance productivity of teams across the globe and one such best practice is one that addresses generating better code.

Pair programming is a practice that requires two developers working together on one workstation. Each member of this two people team is doing something that the other is not currently doing. For e.g., if one is writing a function, the other thinks about how the output of this function will affect the other pieces of code in the class.

The person who is typing is called a driver while the other, who is doing the analyzing, is called the navigator. At the end of a specific period, they switch roles and end of a longer period, partners (usually at the end of a module/task or end of day).

And like everything in the world that follows the yin-yang principle, pair programming has it’s pros and cons. The effect of it application in a project purely depends on the dynamics of the project and the mindsets of its team. I, however feel that the pros outweigh the cons and hence will be listing down the advantages of it.

Increase discipline – Having a pair of eyes look at everything you do tends to influence people to put their best foot forward. It makes people think better and work smarter. It also tends to cut down the breaks that a person takes, since the other’s work is dependent on what s/he does.
Though most people tout this benefit as a watchdog approach, it is not so. The navigator is not a silent spectator judging every move of the driver. This approach takes advantage of the psychological fact the people behave more responsibly in the presence of others.

Better code – Furthering the first benefit listed above, since the navigator is continuously applying his/her mind to think forward, s/he tends to review the code in a better fashion and hence increasing the quality of design and code.

Resilient Flow – Having another person around helps keeping the flow of the activity and maintaining its direction. It’s easier to get back on track if the flow is disrupted. Also, pairs are more resilient to interruptions. If there is an interruption, one can address it while the other continues working.

Multiple contributors to design – Due to the continual rotation of the pairs, everyone is involved in the development of the application. This brings in clarity of design and the opportunity to improve it.

Improved morale - Due to the fact that one is switching tasks with others, it increases competition amongst the team to produce better code. It even increases camaraderie in the team.

Collective Code Ownership – Since everyone has worked on the code, there is no single ownership. Everyone is responsible of every aspect of the code.

Improved understanding of the system – Pair and rotation results in everyone having an improved understanding of the entire system and not just specific modules that they would work on if they were not paired and rotated.

Mentoring – Technical mentoring is painlessly possible using paired programming techniques. This allows the junior members to gain more knowledge that the tradition knowledge transfer.

Lower hardware overheads – Fewer workstations are required since one is shared by two people.

As mentioned earlier, Paired programming does have its list of downfalls, but industry experts state that disadvantages such as increased cost, longer turnaround times, etc are usually short term. Once the practice is institutionalized, teams and organizations have realized that paired programming eventually does result in higher and better productivity, lower reworks and hence cost savings.

For further reading, follow the links below that I have referenced:
http://en.wikipedia.org/wiki/Pair_programming
http://c2.com/cgi/wiki?PairProgrammingPattern
http://www.methodsandtools.com/archive/archive.php?id=10
http://www.comp.polyu.edu.hk/people/doc/cskcchan/pairpaper.pdf http://theagileblog.net/2005/11/stop_demanding_pair_programmin_1.html