Paper Authors

Abstract

NOTE: The first page of text has been automatically extracted and included below in lieu of an abstract

Session 2230

Pair Programming in Introductory Programming Labs

Eric N. Wiebe, Laurie Williams, Julie Petlick, Nachiappan Nagappan, Suzanne Balik, Carol Miller and Miriam Ferzli NC State University, Raleigh, NC

ABSTRACT: This project looks at the practice of pair programming as a vehicle for improving the learning environment in introductory computer science labs, a nearly universal course for all engineering students. Pair programming is a practice in which two programmers work collaboratively at one computer, on the same design, algorithm, or code. Prior research indicates that pair programmers produce higher quality code in essentially half the time taken by solo programmers. A multiyear project is currently underway at North Carolina State University, looking at the efficacy of pair programming in an introductory Computer Science (CS1) course. Results indicate that student pair programmers are more self-sufficient in lab and are more likely to complete the class with a grade of C or better. The effect of pair programming on specific graded exams and projects are less clear. Demographic data, prior achievement scores, and current course scores were brought together with interview data, attitude surveys, and in-lab observations to guide the evaluation. As part of the in-lab data collection, novel techniques are being developed to better understand pair dynamics and student/instructor interactions. Collectively, these evaluative methods have guided the iterative implementation of paired programming instructional methods. Current challenges being addressed include lab instructor training, student/instructor concerns over equity in effort on assignments, pair dynamics in lab, and collaborative logistics of pair programming outside of lab.

I. Introduction Extreme Programming (XP) 1 has popularized a structured form of programmer collaboration called pair programming. Pair programming is a style of programming in which two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, or test. One of the pair, called the driver, is types at the computer or writes down a design. The other partner, called the navigator, has the task of monitoring the driver’s work for tactical and strategic defects. Tactical defects are local errors such as syntax errors, typos, or improper method calls. Strategic errors involve, as the name implies, problems in strategy, leading incorrect or inefficient solutions to programming problems. Because the navigator is not involved in the highly focused work of typing the code, they can afford to look ahead and monitor overall strategy. Still, the driver and navigator continuously spend time brainstorming and negotiating their course of action. Ideally, communication between the driver and navigator is regular with the driver explaining what he or she is doing or asking for advice and/or confirmation of what he or she has done and the navigator providing feedback. The feedback can be pointing out simple errors, providing encouragement, or challenging the driver to explain what was done . An effective programming pair has an active relationship with both halves actively involved in the development of the code or design. Balance in the partnership is preserved by having the two switch roles on a regular basis. Research results 2-4 indicate that pair programmers produce higher quality code in about half the time when compared with solo programmers. Some of this research was conducted at the Proceedings of the 2003 American Society for Engineering Education Annual Conference & Exposition. Copyright 2003, American Society for Engineering Education

• Citation

• Format
  • APA
  • APA - LaTeX bibitem
  • MLA
  • MLA - LaTeX bibitem
  • Bibtex
  • EndNote - RIS

Balik, S., & Nagappan, N., & Williams, L., & Petlick, J., & Miller, C., & Ferzli, M., & Wiebe, E. (2003, June), Pair Programming In Introductory Programming Labs Paper presented at 2003 Annual Conference, Nashville, Tennessee. 10.18260/1-2--12489