1. Pair Programming (PP)

2. What Is Pair Programming [1] XP (Extreme Programming) practise ”Two programmers working side-by-side, collaborating on the same design, algorithm, code or test.” ”Driver” has control over keyboard/mouse ”Observer” [1] or ”Navigator” [5] continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work Periodical role switches

3. Proposed advantages [2] Brainstorming –Two brains are better than one. –The observer challenges the drivers reasoning. Continuous Design Walkthrough –Observer can concentrate on the design and typos. –People tend to be blind to their own errors. Focused Energy –People tend to work more efficiently when challenged Mentor and Communications –Transfer information and understanding –Multiple people understanding different parts –Teams become better

4. Proposed advantages [2] Motivation –PP supposedly increases productivity and reduces errors. –Translates directly to programmer confidence and happiness Pair relaying [4] –Problem solving in isolation usually involves deadlocks, which are extremely time- consuming

5. Possible problems Counter-Productivity –2 programmers = 2 * time used Chemistry problems –Some pairs might not want to work together –Equal pairs might get too competitive [2] Some isolation left [2] –Two is better, but how about many pairs in same room?

6. Our use of PP Will start in I2 –Few well specified programming tasks in I1 as the design is under construction –Architectural challenges make I1 critical and risky. No extra confusion needed. –Collaborative development already via IRC

7. Objectives Assessment of the technique –The power of PP is not universally recognized Better communication and understanding –Design pairs such that information about different parts of the system diffuses effectively Higher productivity –PP supposedly raises productivity Better quality –PP supposedly produces better code

8. Execution Test phase in I2 –constrained application –some problems with facilities and timetables –playing it safe architectural challenges bring uncertainty New assessment in I3 –Usage ramped up if no major obstacles are identified –Desicion not based on measured data

9. Execution Scheduled group sessions in I2 –single room (Maarintalo), 3 pairs, 2 hours, 1 per week Experiences suggest pair isolation is bad Volume can be increased in I3 –no new practises –produce more accurate measurement data

10. Execution Planned in weekly sessions –tasks predefine the tasks to tackle no hassle in sessions –groups make pairs with uneven knowledge of the task and alter roles –time preferably regular times

11. Assessment Measure produced LOC –Use custom tool integrated with CVS –LOC/Effort with PP (includes planning) –Total LOC/Effort –Disciplined PP brings bias Measure defects –Use bugzilla –Reported errors created in PP / LOC –Reported errors created in single programming / LOC Final results in separate PP document.

12. References [1] http://www.pairprogramming.com/http://www.pairprogramming.com/ [2] http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html [3] http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.P DF http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.P DF [4] http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardini a.PDF http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardini a.PDF [5] http://www.cse.ucsc.edu/~brianh/papers/Qualifying.pdf http://www.cse.ucsc.edu/~brianh/papers/Qualifying.pdf [6] http://www.pairprogramming.com/conversantpairing.htm http://www.pairprogramming.com/conversantpairing.htm