1 / 40

Pair Programming: Why Have Two Do the Work of One

Pair Programming: Why Have Two Do the Work of One. from Laurie Williams North Carolina State University. Pair Programming. Agenda. Research/Findings Colocated Pairs Distributed Pairs Pair Interactions Sample Pairings Pair Rotation Summary. Empirical Study for Validation.

emckenna
Download Presentation

Pair Programming: Why Have Two Do the Work of One

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pair Programming: Why Have Two Do the Work of One from Laurie Williams North Carolina State University

  2. Pair Programming

  3. Agenda • Research/Findings • Colocated Pairs • Distributed Pairs • Pair Interactions • Sample Pairings • Pair Rotation • Summary

  4. Empirical Study for Validation • Practice: Summer 1999 • 20 Students (Sophomore/Junior) • All worked collaboratively • Generated more anecdotal/qualitative evidence • Solo vs Pair: Fall 1999 • 41 Students (Junior/Senior) • 28 Worked Collaboratively • 13 Worked Individually • Software development process was controlled • The only experimental variable: pair-programming • Quantitative: Time, Quality, Enjoyment, Confidence

  5. Boxplot of Program Quality

  6. Boxplot of Student Time

  7. Collaboration by Phase

  8. Distributed Pair Programming • Net Meeting • Yahoo Messenger • Graduate Object-Oriented class at NCSU • 5-week project • 132 students • 34 distance students • Teams of 2-4 students • Colocated non-pairs (9 groups) • Colocated pairs (16 groups) • Distance non-pairs (8 groups) • Distance pairs (5 groups)

  9. Productivity

  10. Quality

  11. Satisfaction with Working Arrangement

  12. Satisfaction with Communication

  13. Research Findings to Date • Strong anecdotal evidence from industry “We can produce near defect-free code in less than half the time.” • Empirical Study • Pairs produced higher quality code • 15% less defects (difference statistically significant) • Pairs completed their tasks in about half the time • 58% of elapsed time (difference not statistically significant) • Most programmers reluctantly embark on pair programming • Pairs enjoy their work more (92%) • Pairs feel more confident in their work products (96%) • Distributed pair programming is a viable alternative (worthy of much more research)

  14. How does this work? • Pair-Pressure • Keep each other on task and focused • Don’t want to let partner down • “Embarrassed” to not follow the prescribed process • Parkinson’s Law “Work expands to fill all available time.” • Pair-Negotiation • Distributed Cognition: “Searching Through Larger Spaces of Alternatives” • Have shared goals and plans • Bring different prior experiences to the task • Different access to task relevant information • Must negotiate a common shared of action • Pair-Relaying • Each, in turn, contributes to the best of their knowledge and ability • Then, sit back and think while their partner fights on

  15. How does this work (part two)? • Pair-Reviews • Continuous design and code reviews • Ultimate in defect removal efficiency • Removes programmers distaste for reviews • 80% of all (solo) programmers don’t do them regularly or at all • Debug by Describing • Tell it to the Furby • Pair-Learning • Continuous reviews  learn from partners techniques, knowledge of language, domain, etc. • “Between the two of us, we knew it or could figure it out” • Apprenticeship • Defect prevention always more efficient than defect removal

  16. Vending Machine Program: Responsibility Assignment UIMary Buy Drink Joe Data Structures Charlie Machine Maintenance Sue

  17. Task Owner Partner UI for ‘Buy Drink’ Mary Joe UI for ‘Add Inventory’ Mary Sue UI for ‘Add Recipe’ Mary Sue Input Coins/Return Coins Joe Mary Select Drink Joe Charlie Ingredient Data Structure Charlie Sue Recipe Data Structure Charlie Sue Add Ingredients Sue Charlie Customer Analysis Sue Mary Pair Rotation UI Mary Buy Drink Joe Data Struct. Charlie Mach Maint. Sue

  18. Expected Benefits of Pair-Programming • Higher product quality • Improved cycle time • Increased programmer satisfaction • Enhanced learning • Pair rotation • Ease staff training and transition • Knowledge management/Reduced product risk • Enhanced team building

  19. The Benefitsof Pair Programming Robert Kessler School of Computing University of Utah Special thanks to Laurie Williams North Carolina State University

  20. What Is Pair Programming? "Pair programming is a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. It allows two people to produce a higher quality of code than that produced by the summation of their solitary efforts."

  21. This Is Pair Programming

  22. This is NOT Pair Programming

  23. Pair Programming Has Been Around For a LONG TIME! 1945 . . . 1953 … 1997 1998 1999 2000 2001 2002 John von Neumann, recognized his own inadequacies and continuously asked others to review his work. Fred Brooks and many others are pair programming, though they don’t know there is a name for it.

  24. Does Pair Programming Really Work? • Empirical study by Laurie Williams at the university of Utah • Practice: Summer 1999 • 20 students (sophomore/junior) • All worked collaboratively • Generated more anecdotal/qualitative evidence • Solo vs. pair: Fall 1999 • 41 students (junior/senior) • 28 worked collaboratively • 13 worked individually • Software development process was controlled • The only experimental variable: pair-programming • Quantitative: time, quality, enjoyment, confidence

  25. Findings #1 - Quality

  26. Findings #2 - Time

  27. Findings #3 and #4 – Enjoyment and Confidence

  28. How Does This Work? • Pair-Pressure • Keep each other on task and focused • Don’t want to let partner down • “Embarrassed” to not follow the prescribed process • Parkinson’s law “work expands to fill all available time.” • Pair-Think • Distributed cognition: “searching through larger spaces of alternatives” • Have shared goals and plans • Bring different prior experiences to the task • Different access to task relevant information • Must negotiate a common shared of action • Pair-Relaying • Each, in turn, contributes to the best of their knowledge and ability • Then, sit back and think while their partner fights on

  29. How Does This Work (Part Two)? • Pair-Reviews • Continuous design and code reviews • Ultimate in defect removal efficiency • Removes programmers distaste for reviews • 80% of all (solo) programmers don’t do them regularly or at all • Debug by describing • Tell it to the Furby • Pair-Learning • Continuous reviews  learn from partners techniques, knowledge of language, domain, etc. • “Between the two of us, we knew it or could figure it out” • Apprenticeship • Defect prevention always more efficient than defect removal

  30. Research Findings to Date - 1 • Strong anecdotal evidence from industry • “We can produce near defect-free code in less than half the time.” • Empirical study • Pairs produced higher quality code • 15% less defects (difference statistically significant) • Observed – pairs produced smaller (LOC) programs • Pairs completed their tasks in about half the time • 58% of elapsed time (difference NOT statistically significant) • Most programmers reluctantly embark on pair programming • Pairs enjoy their work more (92%) • Pairs feel more confident in their work products (96%)

  31. Research Findings - 2 • Several educational studies underway • University of California, Santa Cruz; North Carolina State University • What about pair learning? • Anecdotal says that it works well • What are the long-term issues? • If you learn as a pair, can you work as a solo? • Distributed pair programming studies underway • North Carolina State University; University of North Carolina-Chapel Hill • Early results: distributed pair programming is viable • My experience: • Need to meet and know your pair • Need a good tool like VNC and telephone • Video not important

  32. Issues: Workplace Layout Bad Better Best

  33. Issues: Partner Picking Principles Expert paired with an Expert Expert paired with a Novice Novices paired together Professional Driver Problem Culture

  34. Issues: Pair Rotation • Ease staff training and transition • Knowledge management/Reduced product risk • Enhanced team building

  35. Issues: Process • Used in eXtreme Programming • Used in the Collaborative Software Process • Pair programming can be added to any process

  36. Expected Benefits of Pair Programming • Higher product quality • Improved cycle time • Enhanced learning • Pair rotation • Ease staff training and transition • Knowledge management/reduced product risk • Enhanced team building • Increased programmer satisfaction

  37. More Information • Bob Kessler801-581-4653kessler@cs.utah.edu • Laurie Williams919-513-4151williams@csc.ncsu.edu • http://pairprogramming.com • http://collaboration.csc.ncsu.edu/laurie

More Related