Perceptions of Pair Programming

During the fall semester of 2000, the students were required to write two opinion papers chosen from a short list of possible topics. One choice was to address the question, "Should pair programming be taught in the introductory programming courses in our department?"

Twenty of the students chose to address this topic. Fourteen (70%) of the students favored teaching pair programming and six (30%) were opposed.

Once again, the numbers and reasons that follow must be viewed in light of the characteristics of the students as they pertain to this topic. Starting with the first programming course, the students were allowed to work in pairs to develop programs, but the partnerships were casual and unstructured. The pairing was gradually discouraged as they progressed through the curriculum. Some of the students had participated in these informal pairings, while others had not. In addition, many of the students had had recent contact with beginning programmers by working as teaching assistants or laboratory assistants.

Support for Pair Programming

The students who advocated the use of pair programming tended to echo the supporting themes that appear in the literature, including increased learning and comprehension, enhanced communication and teamwork, improved time management, improved self-reliance, improved problem solving and strategic thinking, and more opportunities to experiment and consider alternative solutions.

Some of the students drew from their personal experience to advocate pair programming as a way to increase retention. One student wrote:

Fewer students would abandon their computer science major if pair programming were taught here. I know several students who started out as computer science majors and switched their major because they did not think that they were smart enough to program. Pair programming would put more students at ease because it uses the attitude that two brains are better than one.

Another student, who had failed his first attempt at a programming course, wrote:

Speaking from experience, when first learning a computer language, it seems like learning Chinese. I did not realize that you had to adapt yourself to a different level of intellect and think on a different plane. If I would have been paired with someone, together we could have helped each other adapt to this way of thinking.

Another raised an interesting point concerning pair programming.

The beginning programmer finds it difficult to clearly document code. With a partner looking on in pair programming there would be a constant pressure to write code that another can read.

Opposition to Pair Programming

Most of the students' arguments against using pair programming in the introductory courses were based on what could happen if pair programming practices were not strictly followed by all participants. Several of the arguments expressed the concern that pair programming would not be effective unless both members were competent. The following quotes capture the essence of these arguments.

When people who know a lot are put with people who know nothing, the person who is supposed to be watching for errors doesn't know what an error would look like.

When assignments would be handed out, the more experienced programmer would do all the work so they wouldn't get a bad grade on the assignment.

Some students expressed reservations about whether or not pair programming would be practiced without direct supervision. The following quote expresses this thought very well.

Pair programming requires that two people work on the project at the same time. This would involve work outside the classroom and for people to find time that they are both available. They wouldn't work in pairs if they were supposed to outside of class. One would do this part and the other would do that part. And that wouldn't be pair programming, that would be modular programming.

A few of the concerns dealt with some of the realities of a beginning programming class. What happens when strangers form an incompatible pair? What happens when one member of a pair withdraws from the course or simply stops participating?

Finally, one student expressed a concern about an apparent conflict between the goals of pair programming and the goals of an introductory programming class.

A programming group turning out "products" at an early stage in the learning process is a bad way to look at teaching. The product of a student's efforts is knowledge and understanding, not a chunk of code with a minimal number of errors.

Suggestions from the Students

A few students expanded on the assignment and suggested ways to incorporate pair programming into the beginning programming courses. Most of these suggestions were variations on the theme that pair programming can be used successfully only in a closed laboratory environment. A few suggested that the instructors would have to develop more challenging assignments and adjust their grading criteria.

The most provocative comment came from the student who offered the following suggestion.

The time taken for a student to complete a program would be nearly cut in half, allowing the professor to assign more programs. This would aid the students' knowledge by allowing them to complete more programs.