Abstract:
Previous research [1, 4] has indicated that pair programming is better than individual programming when the pairs are physically colocated. However, important questions arise: How effective is pair programming if the pairs are not physically next to each other? What if the programmers are geographically distributed? An experiment was conducted at North Carolina State University to compare the different working arrangements of student teams developing object- oriented software. The teams were both colocated and in distributed environments; some teams practiced pair programming while others did not. The results of the experiment indicate that it is feasible to develop software using distributed pair programming, and that the resulting software is comparable to software developed in colocated or virtual teams. Our findings will be of significant help to educators dealing with team projects for distance-learning students, as well as organizations that are involved in distributed development of software.
Abstract:
Pair programming is one of the twelve practices of Extreme Programming (XP) [1]. Pair programming is usually performed by programmers who are collocatedworking in front of the same monitor. But the inevitability of distributed development of software gives rise to important questions: How effective is pair programming if the pairs are not physically next to each other? What if the programmers are geographically distributed? An experiment was conducted at North Carolina State University to compare different working arrangements of student teams developing object- oriented software. Teams were both collocated and in distributed environments; some teams practiced pair programming while others did not. In particular, we compared the software developed by virtual teams using distributed pair programming against collocated teams using pair programming and against virtual teams that did not employ distributed pair programming. The results of the experiment indicate that it is feasible to develop software using distributed pair programming, and that the resulting software is comparable to software developed in collocated or virtual teams (without pair programming) in terms of productivity and quality.
Abstract:
Previous research [1, 2] has indicated that pair programming is better than individual programming when the pairs are physically colocated. However, important questions arise: How effective is pair programming if the pairs are not physically next to each other? What if the programmers are geographically distributed? An experiment was conducted to compare the different working arrangements of student teams developing object-oriented software. The teams were both colocated and in distributed environments; some teams practiced pair programming while others did not. The results of the experiment indicate that it is feasible to develop software using distributed pair programming, and that the resulting software is comparable to software developed in colocated or virtual teams. Our early experiments have led to the creation of a more comprehensive environment for support of distributed pair programming, using dual screen projectors and hymermedia-enhanced video streams. Our findings will be of significant help to educators dealing with team projects for distance-learning students, as well as organizations that are involved in distributed development of software.
Abstract:
Undergraduate freshman programming classes are conventionally organized such that individual students complete a set of concept-specific and unrelated programming assignments. This structure does not prepare students for future collaborative efforts or for the future use of software engineering practices. The addition of pair programming into a freshman programming class at the University of California at Santa Cruz (UCSC) showed similar benefits to similar studies on upper-division software classes[1,2], and is expected to show an improvement in students' willingness and ability to participate in complex, collaborative software engineering assignments in later classes. This paper describes the implementation of the pair programming experiment at UCSC, discusses some of the issues that compromised the effectiveness of certain pairs, and provides implementation guidelines for avoiding such issues in other classes.
Abstract:
Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.
Abstract:
Students who pair program bene t in many ways. Compared to students who work alone, students who pair have shown increased con dence in their work, greater success in CS1, and greater retention in computer-related majors. This paper reports on a study in which pairing and solo students were given the same programming assignments. We found that pairing students were more likely to turn in working programs, and the programs they did turn in correctly implemented more required features. Our findings were mixed when we looked at some standard complexity measures of programs. An unexpected but signi cant nding was that pairing students were more likely to submit solutions to their programming assignments.
Abstract:
The purpose of this study was to investigate the effects of pair-programming on student performance in an introductory programming class. Data was collected from approximately 600 students who either completed programming assignments with a partner or programmed independently. Students who programmed in pairs produced better programs, completed the course at higher rates, and performed about as well on the final exam as students who programmed independently. Our findings suggest that collaboration is an effective pedagogical tool for teaching introductory programming.
Abstract:
Abstract:
There is now a substantial body of evidence in support of the use of pair programming in the classroom[3, 4, 10, 11, 13, 14]. Some of the data is anecdotal and some is the result of formal experiments. We are not aware of any published data that raises concerns about allowing students to complete programming projects using pair programming. In this paper we present data from three studies performed at UCSC. All three studies support the position that pair programming results in more student learning.
Abstract:
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. Pair programming is becoming increasingly popular in industry and in university curricula. An experiment was run at North Carolina State University over a period of one and a half years to assess the efficacy of pair programming as an alternative educational technique in an introductory programming course. We found that the retention rate of the students in the introductory programming courses is equal to or better than that of the students in the solo programming courses. Most students show a positive attitude towards collaborative programming, and students in paired classes continue to be successful in subsequent programming classes that require solo programming. Pair programming also leads to a reduced workload for the course staff in terms of grading, questions answered and teaching effort.
Abstract:
Pair programming is a kind of collaborative programming where two people are working simultaneously on the same programming task. It is one of the key practices of eXtreme Programming. In the paper we compare it with two variants of individual programming: one of them is based on Personal Software Process that has been proposed by W. Humphrey, and the other is a variant of eXtreme Programming tailored to individuals. Four experiments are described that has been performed at the Poznan University of Technology. During those experiments 21 students wrote 4 C/C++ programs ranging from 150 to 400 LOC. The obtained results are compared with the results of similar experiments described by J.T. Nosek and L. Williams et al.
Abstract:
We present a hardware/software system for support of distributed Extreme Programming, or DXP. It consists of a dual video projector setup with NetMeeting running on a single PC, and a hypervideo system we built called OvalTine. OvalTine allows the creation and automatic tracking of hyperlinks in a video stream, both archived and real-time (as in video conferencing). DXP supports the development of software by a pair of programmers that is non-co-located. One projector displays a shared PC desktop, and another projector displays a life-sized image of each collaborator to the other. OvalTine integration means developers can add hyperlinks to the collaborator camera stream, integrating it with Web pages or other video streams. The DXP work environment gives a better sense of being there to the pairs in a pair-programming team. We are experimenting with DXP to measure the productivity of distributed software developers working via different technical processes (paired, individual, full XP, traditional).
Abstract:
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.
Abstract:
Anecdotal and qualitative evidence from industry indicates that two programmers working side-by-side at one computer, collaborating on the same design, algorithm, code, or test, perform substantially better than the two working alone. Statistical evidence has shown that programmers perform better when following a defined, repeatable process such as the Personal Software Process (PSP). Bringing these two ideas together, the Collaborative Software Process (CSP) has been formulated. The CSP is a defined, repeatable process for two programmers working collaboratively. The CSP is an extension of the PSP, and it relies upon the foundation of the PSP.
To validate the effectiveness of CSP, an experiment was run in 1999 with approximately 40 senior Computer Science students at the University of Utah. All students learned both the CSP and the PSP. Two-thirds of the students worked in two-person collaborative teams using the CSP to develop their programming assignments. The other students worked independently using the PSP to develop the same assignments. Additionally, a significant amount of input and confirmation from professional engineers who practice collaborative programming was factored into the research. The research contributed a defined, repeatable process, the Collaborative Software Process, for collaborative programming pairs. The experiment validated the following quantitative findings about collaborative teams using the CSP:
1. Collaborative pairs spend approximately 15% more time than do individuals on the same task. This additional time, however, is not statistically significant.
2. Collaborative pairs achieve a higher quality level for programming products. Pairs had 15% less defects in their code. The higher quality level is statistically significant.
3. Considering the long-term field support savings of higher quality programming products, collaborative programming is cheaper for an organization than individual programming.
4. Consistently, 95% of collaborative programmers asserted that they enjoy their work more and are more confident in their work than when they program alone.
Additionally, the research resulted in many qualitative findings about collaborative programming. Most notable are the positive effects of increased problem solving skills, better designs, augmented learning, and improved team building for collaborative pairs. Organizations in which the engineers consistently switch partners also note increased communication, enhanced teamwork, and reduced product risk.
Abstract:
Anecdotal evidence from several sources, primarily in industry, indicates that two programmers working collaboratively on the same design, algorithm, code, or test perform substantially better than the two would working alone. Two courses taught at the University of Utah studied the use of this technique, often called pair-programming or collaborative programming, in the undergraduate computer science classroom. The students applied a positive form of "pair-pressure" on each other, which proved beneficial to the quality of their work products. The students also benefit from "pair-learning," which allowed them to learn new languages faster and better than with solitary learning. The workload of the teaching staff is reduced because the students more often look to each other for technical support and advise.
Abstract:
Industry, particularly those following the eXtreme Programming (XP) methodology [2], has popularized the use of pair-programming. The pair-programming model has also been found to be beneficial for student programmers. Initial quantitative and qualitative results, which will be discussed in this paper, demonstrate that the use of pair-programming in the computer science classroom enhances student learning and satisfaction and reduces the frustration common among students. Additionally, the use of pair-programming relieves the burden on the educators because students no longer view the teaching staff as their sole form of technical information. We explore the nature of pair-programming, then examine the ways such a practice may enhance teaching and learning in computer science education.
Abstract:
Prior research indicates that pair programming, whereby two programmers work collaboratively on the same design, algorithm, code, or test, produces higher quality code in essentially half the time taken by solo programmers. An experiment was run at North Carolina to assess the efficacy of pair programming in the introductory CS1 course. Results indicate that relative to students who program individually, pair programmers are more self-sufficient, perform better on projects, and are more likely to complete the class with a C or better
Abstract:
A formal pair programming experiment was run at North Carolina to empirically assess the educational efficacy of the technique in a CS1 course. Results indicate that students who practice pair programming perform better on programming projects and are more likely to succeed by completing the class with a C or better. Student pairs are more self -sufficient which reduces their reliance on the teaching staff. Qualitatively, paired students demonstrate higherorder thinking skills than students who worked alone. These results are supportive of pair programming as a collaborative learning technique.
Abstract:
Anecdotal and statistical evidence [1-3] indicates that pair programmers -- two programmers working side-by-side at one computer, collaborating on the same design, algorithm, code or test -- outperform individual programmers. One of the programmers, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software. This practice of pair programming can be integrated into any software development process. As an example, this paper describes the changes that were made to the Personal Software Process (PSP) to leverage the power of two programmers working together, thereby formulating the Collaborative Software Process (CSP). The paper also discusses the expected results of incorporating pair programming into a software development process in which traditional, individual programming is currently used.
Last Update: 11/20/03.