CSC/ECE 517 Fall 2012/ch2a 2w9 ms

From PG_Wiki
Jump to: navigation, search
Pair programming

"The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant."
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition[1]

Pair Programming

This chapter will explain basic concepts of pair programming which is one of the popular Agile Software Development technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

Contents


Introduction

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. Use of this practice has been demonstrated to improve productivity and quality of software products.[2].

In Pair programming practice, two software engineers work on one task at one computer. One of the engineer acts as a driver who has control of the keyboard and mouse and (s)he writes the code for an implementation. The other engineer acts as a navigator (also called as an observer) and watches and reviews the driver's implementation to identify defects and participates in on-demand brainstorming. The roles of driver and navigator are periodically rotated between the two software engineers. The observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his/her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

Pair programming is one of the corollary practices of Extreme Programming. Extreme Programming (XP), is an emerging software development methodology. Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. In this practice the programmers constantly communicate with the customers and fellow programmers for continuous improvement [3]. XP attributes great success to the use of “pair programming". XP advocates pair programming with such fervor that even prototyping done solo is scrapped and re-written with a partner.

Back to top

Principles of Pair Programming

There are some principles of pair programming in the context of Fulghum's Poem [4].

Share everything

In pair programming, two programmers are required to produce one piece of software (design, algorithm, code etc.) within a specified time limit. The two programmers are working with one mind responsible for every aspect of this piece of software. Both the driver and a navigator are equal participants in the process and both of the partners own everything and hence they should not blame each other for any defect in the artifact.

Play fair

With pair programming, one person has control of the keyboard or is recording design ideas, while the other is continuously reviewing the work. Even when one programmer is significantly more experienced than the other, it is important to take turns “driving,” so that the observer does not become disjoint or feel unimportant.

Don't hit your partner

Make sure your partner stays focused on task. The driver is awaiting continuous contribution and input from the navigator and hence both the partners should be focused on their part of work.

Clean up your mess

Pair programming makes many obvious unnoticed defects go away because of another person watching over the shoulders. Additionally, these defects can be removed without the natural animosity that might develop in a formal inspection meeting.

Don't take things too seriously

Pair programming demands ego-less programming approach from both the partners. It is essential for effective programming effort. Excess ego can manifest itself in two ways, both damaging the collaborative relationship. Attitude problems can prevent the programmer from considering others ideas. Secondly, excess ego can cause a programmer to be defensive when receiving criticism or to view this criticism as mistrust.

Take a break from working together

It is acceptable to work alone 10-50% of the time. Many programmers prefer to do experimental prototyping and logical thinking alone. Simple, well defined coding is more efficiently done by a solitary programmer and then reviewed with a partner.

Be aware of the power of two brains

Human beings can remember only to a certain extent and hence one must consult others to increase their knowledge. When two people are working together, each one has their own set of skills and expertise, which should be properly used while producing a piece of software. The unique skills of each individual will allow them to engage in interactions which pool their resources to accomplish their tasks.

Back to top

Partner picking principles

Pair programming


Back to top

How to achieve Pair Programming

There are some ways to achieve pair programming for an effective development process [5].

Back to top

When to use Pair Programming

Pair programming can be beneficial in certain scenarios. Some of them are mentioned here [6].

Pair Programming Benefits/Advantages

Back to top

Pair Programming Disadvantages

Back to top

Research

Academia

A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" [7]. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

Industry

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" [8]. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

Back to top

Conclusion

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

Back to top

See also

References

  1. Gerald Weinberg
  2. Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten
  3. http://www.extremeprogramming.org/
  4. http://anh.cs.luc.edu/170/Kindergarten.html
  5. http://www.wikihow.com/Pair-Program
  6. http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html
  7. Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course
  8. Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox