Jump to content

Pair Programming

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Mda uz (talk | contribs) at 06:47, 31 January 2007 (This article gives a brief information about pair programming. It uses the specified references as resources.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Redirect page

Redirect to:

Mda uz 06:47, 31 January 2007 (UTC)mda_uz

Introduction

Pair programming is a programming style in which two programmers work together at one computer, one typing and the other thinking, and taking turns doing so. They collaborate on the same code, project, design, or algorithm with the same purpose: to achieve the best solution to a problem. Pair programming is proved to help achieve better ideas, continuous collaboration of the two programmers, and enhance the programmers' communication and programming skills. It also helps improve productivity and quality of the work being done while also allowing the programmers to interact and come up with solutions more faster and more efficiently than when they worked separately.

Advantages

Pair programming has many benefits. It is practiced in order to yield efficient results in the success of which each programmer has confidence. When pair programming, the programmer doing the thinking and editing what the other one typed can catch the typist's errors and point out more efficient ways to write the code. They take turns typing and thinking, thus yielding dependable solutions and correcting each others' mistakes. Pair programmers give feedback, review each other's code and notice unnoticed defects; they think faster working together and come up with trustable ideas, and they improve their performance and programming skills. Here are a few benefits of this style of programming:

  • Confidence - programmers who program in pairs have more confidence in their work than those who program alone
  • Discipline - a programmer working alone is more likely to slack off and take long breaks while programming; when working in pairs, each programmer keeps the other on task and informed
  • Code Improvement - in programming, two brains are better than one; they produce better algorithm, better design, and eventually, better code
  • Focus - each programmer keeps the other on task by doing his/her job; both of the programmers ask each other questions or make comments on how the work is being done to keep each other well informed and attuned
  • Team cohesion - pair programming enforces communication and interaction, which helps the programmers get to know each other
  • Mentoring - one programmer may know something that the other one does not and pair programming is the way to acquire more knowledge or catch mistakes one may continuously make


Making the Transition

It may be difficult for a programmer who mostly programs alone to get used to working with a partner. There may be gains or losses in his/her productivity or he/she may prefer peaceful environment. When adjusting oneself to the task, a program should take into account the pace of the other programmer to solve a problem rather than assuming the whole responsibility of solving it without consulting the partner in terms of agreement. Both programmers have to agree to the development of the code in order for them to have confidence in the results. It is important to work fairly and switch tasks. One should stay committed and interested for the program to have a happy ending.

Evidence of Success

"Anecdotal and initial statistical evidence indicates pair programming is highly beneficial. Extreme Programing (XP), an emerging software development methodology, attributes great success to the use of 'pair programming.' XP was developed initially by Smalltalk code developer and consultant Kent Beck with colleagues Ward Cunningham and Ron Jeffries. The evidence of XP's success is highly anecdotal, but so impressive that it has aroused the curiosity of many highly-respected software engineering researchers and consultants. The largest example of its accomplishment is the sizable Chrysler Comprehensive Compensation system launched in May 1997. After finding significant, initial development problems, Beck and Jefries restarted this development using XP principles. The payroll system pays some 10,000 monthly-paid employees and has 2,000 classes and 30,000 methods, (Anderson 1998), went into production almost on schedule, and is still operational today. Additionally, programmers at Ford Motor Company, spent four unsuccessful years trying to build the Vehicle Cost and Profit System (VCAPS) using a traditional waterfall methodology. The XP developers successfully implemented that system in less than a year using Extreme Programming (Beck 1999). XP attributes great success to the use of "pair programming." All production code is written with a partner. XP advocates pair programming with such fervor that even prototyping done solo is scrapped and re-written with a partner. One key element is that while working in pairs a continuous code review is performed, noting that it is amazing how many obvious but unnoticed defects become noticed by another person watching over their shoulder. Results (Beck 1999) demonstrate that the two programmers work together more than twice as fast and think of more than twice as many solutions to a problem as two working alone, while attaining higher defect prevention and defect removal leading to a higher quality product." (1999 Laurie Williams and Robert Kessler 1)


References

Retrieved from "https://en.wikipedia.org/w/index.php?title=Pair_Programming&oldid=104527515"