A Pilot Study

The reported classroom experiences with pair programming tend to involve upper-division students [Wells2001; Williams+2000A]. Is pair programming a reasonable practice for students in lower-division courses? This author conducted a pilot study to assess the feasibility of using pair programming in a data structures course.

During the summer term of 2001, the data structures course had a small enrollment that was very representative of the diversity of students who normally take the course representative in terms of age, gender, ethnicity, family obligations, job schedules, majors and minors, and grade point averages. The first day of the semester, the students were asked to read two articles on pair programming [Williams+2000A; Williams+2000C] and were told that pair programming was to be used for all programming assignments during the semester. The students were then required to write a few sentences that described their initial impressions of pair programming. As was the case with the students in software engineering, the students were generally enthusiastic but expressed a few concerns about scheduling, personality clashes, and work habits.

Because this course lacked a separate laboratory component, some regular class periods were converted to closed laboratory sessions. The initial stages of each programming assignment were completed in the laboratory sessions. The instructor (this author) monitored the students' application of pair programming and made suggestions for improvement. After a few laboratory sessions, the teams were allowed to complete the assignments on their own time, but they were still expected to practice pair programming.

The students completed two questionnaires about their experience with pair programming one after the first assignment and one at the end of the semester. As one would expect, their perceptions changed.

Initially, communication difficulties and schedule conflicts were seen as the major difficulties. By the end of the semester, most of the communications difficulties had been resolved, but finding time to meet and work outside of class was still a problem. As the semester progressed, a new difficulty arose in pairs of significantly differing abilities. The stronger student in each of these pairs grew frustrated with having to explain everything to the weaker student.

When asked to describe the positive benefits of pair programming, the results were consistent with those reported in the literature [Williams+2000C]. Most students reported improved relations with their partner, more efficient defect avoidance, and apparently shortened development times as the primary benefits.

Finally, the students were asked whether pair programming was feasible for use in the data structures course during the regular semester. Early in the summer, the unanimous answer was "yes," but the early enthusiasm waned. The majority believed that pair programming was a valuable practice but that it should be delayed until a later course. They strongly recommended that the pairs be of roughly equal ability and that all pair programming activities occur in laboratory sessions.