Monday, April 22, 2013

Remote Pair Programming for the Masses


I am submitting this project for funding from my University.  It concerns creating an online calendar in which students from around the world can register their interest in remote pair programming.  Evidence is mounting that pair programming is the most effective way to learn how to program, and also generates higher quality code faster.  One of the key challenges is finding someone to pair with; however an appropriately structured calendar that took into account timezone differences, programming skill level etc., could create an environment where there was always someone ready to pair program with you day or night.

Project Description

Pair programming is the process whereby two programmers work together on the same coding problem.  Usually one will act as a navigator and the other as a driver with control of the keyboard.  The central idea is that there is an immediate feedback loop whereby the navigator can check the code the driver creates and the two can discuss possible alternatives.  This is similar to the kind of feedback that may come from code reviews and project retrospectives, but is on a much smaller timescale.
Pair programming is being increasingly adopted in industry although there is a general resistance based on the fear productivity will be lower given that two programmers could be working on two different tasks.  However Cockburn & Williams (2000) demonstrated the following significant benefits of pair programming:
  • many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews)
  • the end defect content is statistically lower (continuous code reviews)
  • the designs are better and code length shorter (ongoing brainstorming and pair relaying)
  • the team solves problems faster (pair relaying)
  • the people learn significantly more, about the system and about software development (line-of-sight learning)
  • the project ends up with multiple people understanding each piece of the system
  • the people learn to work together and talk more often together, giving better information flow and team dynamics
  • people enjoy their work more

Cockburn & Williams go on to point out that the development cost for these benefits is not the 100% that might be expected, but is around 15%; which is quickly paid back for in shorter and less expensive testing, quality assurance, and field support.  Of particular note are the learning benefits, which have also been noted by Williams & Kessler (2003) who indicate that:
"Knowledge is constantly being passed between partners, from tool usage tips to design and programming idioms. The partners take turns being the teacher and the student. Even unspoken skills and habits cross partners."
Canfora et al (2007) found a reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity, while a number of other studies found similar improvements (Lui, 2006; Arisholm et al., 2007; Lui et al., 2008), however meta-analyses have cautioned that this all depends on a number of factors and that you cannot expect “faster and better and cheaper” (Hannay et al., 2009).

Independently of whether pair programming is more effective than solo programming, the educational benefits seem clear.  McDowell et al (2002) and Salleh et al. (2011) both found that students’ grades and satisfaction improved with pair programming as compared to programming solo.  Furthermore McDowell et al. (2002) saw increases in retention indicating that the use of pair programming could prevent students from dropping out.

Schümmer  & Lukosch (2009) describe some of the additional difficulties faced when pair programming remotely, and there are also concerns that productivity and satisfaction can drop during novice-novice pairing is used without sufficient availability of a mentor for coaching (Stephens & Rosenberg, 2003).  All of this indicates that there is a huge pedagogical potential for remote pair programming, but that the process needs to be carefully scaffolded to ensure successful outcomes.

Specific Aims
  • Create online calendar for remote pair programming (RPP)
  • Provide support for editing, discovery and matchmaking
  • Scaffolding successful RPP sessions
  • Recording RPP sessions for analysis
  • Using results of analysis to improve the RPP experience

Significance

The significance of this work is that it is becoming clear that pair programming is the fastest and most effective way to learn how to program, and yet in general it can be very challenging to find pair programming opportunities.  A well organized calendar that allowed students from around the world to discover other students available to pair program could be invaluable in increasing student satisfaction and minimizing the amount of time required to become a confident programmer.

Work so far

We have created a shared Google calendar and sign up form that now has 30 students signed up.  Remote pair programming sessions have been recorded with at least 10 of these students and a preliminary analysis of one session has been conducted.

Bibliography
  • Arisholm, Erik; Hans Gallis, Tore Dybå, Dag I.K. Sjøberg (February 2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise". IEEE Transactions on Software Engineering 33 (2): 65–86.
  • Canfora, Gerardo; Aniello Cimitile, Felix Garcia, Mario Piattini, Corrado Aaron Visaggio (2007). "Evaluating performances of pair designing in industry". The Journal of Systems and Software 80 (80): 1317–1327.
  • Cockburn, A. & Williams, L. (2000). "The Costs and Benefits of Pair Programming". Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).
  • Hannay, J. E.; Dybå T., Arisholm E., Sjøberg D. I. K.  (2009). "The Effectiveness of Pair Programming: A Meta-Analysis". Information and Software Technology 51 (7): 1110–1122.
  • Lui, K. M. (2006). "Pair programming productivity: Novice-novice vs. expert-expert". International Journal of Human-Computer Studies 64 (9): 915–925
  • Lui, K. M., Chan K. C. C., Nosek J. T. (2008). "The Effect of Pairs in Program Design Tasks". IEEE Transactions on Software Engineering 32 (2): 197–211.
  • McDowell, C., Werner, L., Bullock, H., & Fernald, J. (2002). The effects of pair-programming on performance in an introductory programming course. ACM SIGCSE Bulletin, 34(1), 38-42.
  • Salleh, N., Mendes, E., Grundy, J.C. (2011) Empirical Studies of Pair Programming for CS/SE Teaching in Higher Education: A Systematic Literature Review. IEEE Trans. Software Eng. 509-525.
  • Schümmer, T. & Lukosch S. (2009) "Understanding Tools and Practices for Distributed Pair Programming". Journal of Universal Computer Science 15 (16): 3101–3125.
  • Stephens M. & Rosenberg D. "Extreme Programming Refactored: The Case Against XP", Berkeley, CA: Apress, 2003.
  • Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. ISBN 0-201-74576-3.





No comments: