Paired Programming



The idea behind pair programming is the agile concepts of software development technique, where two programmers work together at one workstation. With such environment, one of the programmers will be writing the code, and other programmer will be reviewing each line of code written by the first programmer. As the programmer reviewing the code, the observations of different aspects; and considerations can come into play to implement strategic direction of the work, come up with different ideas to improve the future problems that can be addressed quicker than in normal programming environment. With such environment, the roles of the programmers can be switched during the development hours (Awood, 2007).  


Pair Programming


The good idea about having such environment is the fact that two people can think about the same problems at the same time, also testing the written code can be done regularly that can increase the quality of the written code. Other advantage of such environment is that the skills; and the speciality can be transferable between the two programmers where the ad-hoc training occurs during the development process. The end result of such process can end up with both programmers are fully aware of the code, why it was done that way, and how such code is working. Also, the chances of producing a high quality code in most cases is quite possible, where the code can be less likely to contain bugs or issues that might cause maintenance problems once the system is running in production environment (Awood, 2007).


Awood (2007) explained that with an environment that includes more than two programmers, switching between team members to partner with different programmers can add a huge advantage, where brainstorming; and ideas that can be communicated among the team can be increased dramatically. Such work environment can increase productivity, and the code can be developed quicker without having such code to be revisited for reviews. Some of the benefits of the pair programming are:


  • The constant code review that can happen periodically among developers that can increase productivity in a long run, and enhance the code quality.
  • Exchanging the experience, and the techniques among developers.
  • Eliminating bugs, and common coding mistakes that can be easily avoided through the constant code review process.


Awood (2007) also argued that some of the disadvantages of such programming methodology are the following:


  • Despite the fact that the end result of the product is with higher quality, the day-to-day progress is slower, and that might impact the projects that has restricted deadlines.
  • The practice of such programming technique requires oversight, and discipline to ensure that the pair programming routines is being followed.
  • Having to work closely with someone it can be attractive to some people, while it might not be for others.
  • Pair programming can be turned into many cases to be just a code review process. (n.d.) explained that measuring the programmer’s productivity to be able to understand the elements that might affect such productivity is a difficult task to achieve. The difficulty in measuring productivity is coming from the fact that the developers are entailed with many things that can’t be measured, such as coming up with details, and specified set of instructions that are called programs that can deal with specific needs within the software. Also, programmers involved in testing the logical structure of the program that can be used in solving different problems, where it might reduce the programmer’s productivity. All of the above can take time, and such time can be different from one scenario to another. 


Wegrzanowski (2007) explained that with today’s technologies it is possible for any IT projects to get more functionality in less time with a smaller team than in the past. There are no doubts that improving the development tools and its environment is a big factor in increasing programmers’ productivities.Krishna(2011) also suggested that programmers’ productivity can be increased by implementing different approaches of the programming techniques, such as test-driven development (TDD) where such method can force developers to design a perfect code, and think about how the code will be tested. Another way of increasing productivity and code quality; is raising the questions that can help programmers to implement the right code from the first time. Some of these questions that might be raised are: what functionality the developer is trying to achieve? What different conditions and possibilities that should be taken into account? Having more of these questions will definitely increase code quality, and increase productivity by having a roadmap of thinking.


 Hastie (2010) represented four mechanisms that make effective pair programming works, and can produce a successful experience to many programmers:


  • Pair programmers Chat – Such mechanism can bring the most effective solution to the discussion table, and also help perceive each other’s knowledge.
  • Pair programmers Notice More Details – More mistakes can be discovered, and the accuracy of finding bugs; and avoiding common mistakes can be improved.
  • Fighting Poor Practices – Having pair programmers working together can eliminate the poor practices, and introduce the code-and-fix methods to the programming technique that can increase code quality.
  • Sharing and Judging Expertise – Sharing ideas, and exchanging expertise between pair programmers can increase productivity, and can help implement better coding techniques.




Despite the fact that pair programming is the most controversial agile development practice, it’s a valued method for code quality. Such method can be avoided by many programmers, since it brings uncomfortable situations to many professionals. Pair programming can be challenging for some people since working closely with a person can bring other hidden personal issues to the surface where it can affect productivity. Also, pairing up with others might create dynamic challenges, where one can bring unconventional solutions; and different styles to the table, while the other can prefer the traditional way of thinking and bringing the solutions. However, code review and bringing different techniques to solve a specific problem can bring huge benefits to the code quality (Mountford, 2009).


 Fermandez (2009) explained that pair programming is one of the most competitive advantages that can increase code quality, and reduce bugs. Some of the reasons that can take away these benefits for such method are:


  • Most of the IT managers don’t want to invest in the necessary hardware that can implement the solution for pair programming.
  • Most of the software houses/shops are not configured with their workspace and furniture for pair programming.
  • Most software houses/shops not doing the extra steps in hiring the right talented people for the job, and using the traditional hiring practices that can lead to poor candidates.
  • Tolerating the anti-social behaviours within organizing, can make it difficult for such method to be implemented.


Finally, pair programming requires that two software engineers to participate in a combined effort to develop a high quality code, and introduce the right techniques for solving software problems. That said; it is important that the workplace and the culture within the organization to encourage such behaviours to increase productivity, and enhance the code quality.




Awood, J. (2007) Pair Programming vs. Code Reviews [Online]. Available from: (Accessed: 13 May 2011).


Fermandez, O. (2009) 10 Reasons Pair Programming is Not For the Masses [Online]. Available from: (Accessed: 13 May 2011).


Hastie, S. (2010) How Pair Programming Really Works [Online]. Available from: (Accessed: 13 May 2011).


Krishna(2011) Improving Programming Productivity [Online]. Available from: (Accessed: 13 May 2011).


Mountford, C. (2009) Pair Programming is Kryptonite! [Online]. Available from: (Accessed: 13 May 2011). (n.d.) How to measure and Increase Programmer Productivity [Online]. Available from: (Accessed: 13 May 2011).


Wegrzanowski, T. (2007) Programmer Productivity Doubles Every 6 Years [Online]. Available from: (Accessed: 13 May 2011).





Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: