Guidelines for the Use of Pair Programming in a Freshman Programming Class

1. Guidelines for the Use of Pair Programming in a Freshman Programming Class Jennifer Bevan, Linda Werner, Charlie McDowell Department of Computer Science University of California, Santa Cruz {jbevan,linda,charlie}@soe.ucsc.edu

2. Problem Statement • Initial exposure to computers and programming directly affects the retention of students within the field. • Conventional introductory programming classes do not prepare students for later collaborative work. • How do we increase retention and prepare students for working within a group?

3. Solution Approach • We used pair programming in the freshman programming class at UCSC for three quarters, as part of an NSF research project. • Good early results were achieved, but some pairs were unstable or ineffective. • The problems encountered by these pairs were used to create guidelines for future implementations of pair programming.

4. Background • Pair programming is one aspect of eXtreme Programming (XP). • Partners alternate between driving and observing at (in our case) 1-hour intervals. • All or most individually produced code is treated as a throwaway prototype. • Reduces ego involvement, typographical bugs, improvisational design changes.

5. Implementation Details • 3 classes, with 3 different instructors, used pair programming (Fall 00, Winter 01). • 1 class, with an instructor who previously used pair programming, did not (Spring 01). • Each class required 9 programming assignments (one per week). • 2 TAs were assigned for each class.

6. Implementation Details (cont.) • Paired students were required to submit individual logs for each assignment: • Time spent driving, observing, and working alone; confidence in solution; satisfaction with the experience. • Unpaired students submitted similar logs: • Time spent; confidence in solution; satisfaction with the experience.

7. Class-Level Implementation • 2 of the paired classes had mandatory sections, 1 did not. • 1 of the paired classes only allowed pairing within sections, 2 allowed pairing between sections. • Week n assignments covered similar material but varied in the expected average solution time.

8. Pairing Difficulties • Inability to schedule enough time together. • Unreliability of a partner. • Friction caused by different experience levels and/or rates of learning. • Lack of understanding or caring about the pair programming guidelines. • Unwillingness to raise these issues in a timely fashion.

9. Scheduling Conflicts • Just under 5% of all pairs had significant scheduling/reliability problems. • Students’ methods of handling these problems were hampered by inexperience with a 10-week term. • Scheduling difficulties were exacerbated between partners that were not enrolled in the same section.

10. Experience Conflicts • Just under 2% of the pairs experienced friction due to differing experience levels or rate of learning. • These “higher” level students thought: • Pairing is a waste of their time. • They are not required to be teachers. • Better to just complete the assignment alone and submit it with both names (!).

11. Understanding and Buy-In Issues • Some pairs divided and conquered. • Others alternated development by emailing the latest version back and forth. • Some partners did not want to drive at all. • In most cases, this behavior was discovered, not reported. • These issues were caused by a lack of understanding or caring.

12. Overcoming Pair Problems • Most of these students do not have the experience or the inclination to quickly resolve these problems. • Introductory programming courses need to agressively address these issues. • Classes need to be structured within constraints of TA and instructor time limits.

13. Pairing Guidelines 1 • Pair Within Enrolled Sections • Reduces scheduling problems by using enrollment system as conflict resolver. • TAs can facilitate ice-breaking activities and partner test-drives during first-week sections.

14. Pairing Guidelines 2 • Pair (somewhat) by skill level • Ask student about willingness to work with a partner of a higher or lower level. • Unwilling students can be paired with others at a similar level. • After one successful pairing, willingness to accept another partner increases. L. Williams, R. Kessler, W. Cunningham, and R. Jeffries, “Strengthening the case for pair programming,” IEEE Software, vol. 17, pp. 19-25, July 2000.

15. Pairing Guidelines 3 • Make Sections Mandatory • TA can identify reliability problems faster, because both partners are expected to be present. • Students’ grades are linked to meeting with partner. • A set of acceptable excuses and attendence requirements add little work for TA or instructor.

16. Pairing Guidelines 4 • Assign Work as a Function of Section Time • Tailor the problem size such that an acceptable percentage of the pairs finish during section. • Does not reduce topic coverage, only reduces overhead and busywork. • Requires planning by instructor.

17. Pairing Guidelines 5 • Institute a coding standard • Experienced programmers can code to a standard regardless of opinions on readability, past familiarity, etc. • Most others have their own “right” style. • Reducing conflicts between styles reduces conflict between partners.

18. Pairing Guidelines 6 • Create a Pairing-Oriented Culture • Openly discuss common problems in-class or in-section. • Reiterate goals of pair programming. • Added awareness can lead to self-correction of problems. • Submission and grading policies need to support collaborative process.

19. Why Bother? • “Not that many pairs had problems” • Small target size doesn’t prohibit simple solutions. • “Their degree is an individual achievement” • The workplace is a collaborative environment. Any preparation is helpful. • “My students wouldn’t have these problems” • We didn’t think so either.

20. Conclusions • Many valuable lessons learned from the variety of pair-programming implementations during our experiment. • Introductory classes have several common problems not frequently found in workplace (or upper division) environments. • Time management, scheduling support, professional behavior not developed.

21. Conclusions (cont.) • We developed guidelines for future implementations that address these problems. • As more introductory classes adopt pair programming, these guidelines should be expanded and adapted. • Paper on impact of pair programming to be presented at SIGCSE 2002.

22. Acknowledgements • Dr. Heather Bullock, Dr. Julian Fernald, Wendy R. Williams, M.S, and Tristan Thomte, from the Psychology Department at UCSC. • Dr. Alex Pang and Dr. Scott Brandt from the Computer Science Department at UCSC. • Project funding by the National Science Foundation (NSF EIA-0089989, “Retaining women in computer science: Impact of pair programming”).

23. Thanks! Any Questions?