Pair programming

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found.

Two co-workers pair programming

Pair programming (sometimes referred to as peer programming) is an agile software development technique in which two programmers work as a pair together on one workstation. One, the driver, writes code while the other, the observer, pointer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.

While reviewing, 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 or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

Advantages

Economics
Pairs spend about 15% more time on programs than individuals. However, the resulting code has about 15% fewer defects. Along with code development time, other factors like field support costs and quality assurance also affect the expenses. IBM reported spending about “$250 million repairing and reinstalling fixes to 30,000 customer-reported problems”. Pair programming significantly reduces these expenses by reducing the defects in the programs.[2]
Design quality
A system with two programmers possesses greater potential for the generation of more diverse solutions to problems for three reasons: (1) the programmers bring different prior experiences to the task; (2) they may access information relevant to the task in different ways; (3) they stand in different relationships to the problem by virtue of their functional roles. In the attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.[3]
Satisfaction
In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone. Additionally, 95% of the surveyed programmers stated that they were more confident in their solutions when they pair programmed. A correlation exists between satisfaction among programmers and their confidence in the code i.e. the pairs enjoy their work more because they are more confident in it.[4]
Learning
Knowledge is constantly shared between pair programmers, from tips on programming language rules to overall design skill.[5] In "promiscuous pairing", each programmer communicates and works with all the other programmers on the team rather than pairing only with one partner, which causes knowledge of the system to spread throughout the whole team.[2] Pair programming allows the programmers to examine their partner's code and provide feedback which is necessary to increase their own ability to develop monitoring mechanisms for their own learning activities.[5]
Team-building and communication
Pair programming allows team members to share problems and solutions quickly making them less likely to have hidden agendas from each other. This helps pair programmers to learn to communicate more easily. “This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”[2]

Studies

There are both empirical studies and meta-analyses of pair programming. The empirical studies tend to examine the level of productivity and the quality of the code, while meta-analyses may focus on biases introduced by the process of testing and publishing.

Empirical studies

Pairs typically consider more design alternatives than programmers working alone, and arrive at simpler, more maintainable designs; they also catch design defects early.[6]

Although pair programmers may complete a task faster than a solo programmer, the total number of man-hours increases. A manager would have to balance faster completion of the work and reduced testing and debugging time against the higher cost of coding. The relative weight of these factors can vary by project and task. The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[7] On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity.[7][8] Productivity can also drop when novice–novice pairing is used without sufficient availability of a mentor to coach them.[9]

The matter of the superiority of pair programming over solo programming involves various factors like the experience and skill of the programmers and the complexity of the task. Pair programming could be helpful for attaining high quality and correctness on complex programming tasks, but it would also increase the development effort (cost) significantly. Pair programming may reduce the code development time but also risks reducing the quality of the program. Thus the meta-analysis concluded that "pair programming is not uniformly beneficial or effective".[6]

Indicators of non-performance

There are indicators that a pair is not performing well:

  • Disengagement may present as one of the members physically withdraws away from the keyboard, accesses email, or even falls asleep.
  • The "Watch the Master" phenomenon can arise if one member is more experienced than the other. In this situation, the junior member may take the observer role, deferring to the senior member of the pair for the majority of coding activity. This can easily lead to disengagement.
  • Silence immediately indicates a lack of collaboration.[10]

Pairing variations

Expert–expert
Expert–expert pairing may seem to be the obvious choice for the highest productivity and can produce great results, but it often yields little insight into new ways to solve problems, as both parties are unlikely to question established practices.[7]
Expert–novice
Expert–novice pairing creates many opportunities for the expert to mentor the novice. This pairing can also introduce new ideas, as the novice is more likely to question established practices. The expert, now required to explain established practices, is also more likely to question them. However, in this pairing, an intimidated novice may passively "watch the master" and hesitate to participate meaningfully. Worse still, the Expert may simply withdraw their labor and get employment elsewhere.[11]
Novice–Novice
Novice–Novice pairing can produce results significantly better than two novices working independently, although, this practice is generally discouraged.[2]

Remote pair programming

Remote pair programming, also known as virtual pair programming or distributed pair programming, is pair programming in which the two programmers are in different locations,[12] working via a collaborative real-time editor, shared desktop, or a remote pair programming IDE plugin. Remote pairing introduces difficulties not present in face-to-face pairing, such as extra delays for coordination, depending more on "heavyweight" task-tracking tools instead of "lightweight" ones like index cards, and loss of verbal communication resulting in confusion and conflicts over such things as who "has the keyboard".[13]

Tool support could be provided by:

Pair programming outside software development

Outside of software development, pair work[17] draws directly on the structure and practices of pair programming. Two workers collaborate as a pair at the same workstation (or workspace) taking on the role of driver, who is responsible for doing the work (be that writing, developing, building, etc.), and observer, who is responsible for advising and reviewing the work. Like pair programming, the workers switch roles and pairs frequently. Business functions that operate with a high degree of complexity and risk or where team members need to share skills are more likely to benefit from pair work practices. Common business functions that use pair work include human resources, finance, trading[18] and education.[19]

See also

References

  1. ↑ Lua error in package.lua at line 80: module 'strict' not found."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."
  2. ↑ 2.0 2.1 2.2 2.3 Lua error in package.lua at line 80: module 'strict' not found.
  3. ↑ Flor, N.V. and E.L. Hutchins. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers. 1991: Ablex Publishsing Corporation.
  4. ↑ Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries. “Strengthening the Case for Pair Programming.” IEEE Software. IEEE Software, July–Aug. 2000. Web. 4 October 2013
  5. ↑ 5.0 5.1 Richard L. Upchurch, Laurie Williams. “In Support of Student Pair Programming.” ACM SIGCSE. ACM Publications, March 2001. Web. 4 October 2013
  6. ↑ 6.0 6.1 Lua error in package.lua at line 80: module 'strict' not found.
  7. ↑ 7.0 7.1 7.2 Lua error in package.lua at line 80: module 'strict' not found.
  8. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  9. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  10. ↑ http://www.agilesherpa.org/agile_coach/engineering_practices/pair_programming/
  11. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  12. ↑ Flor, Nick (2006). Globally distributed software development and pair programming. Communication of the ACM, 49, 57–58.
  13. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  14. ↑ Agile Ajax: Pair Programming with VNC
  15. ↑ Pair Programming – The Ultimate Setup and the other options we tried. – Jonathan Cogley's Blog
  16. ↑ Ola Lindberg › Computer ergonomics and pair programming
  17. ↑ Leybourn, E. (2013). Directing the Agile Organisation: A Lean Approach to Business Management. London: IT Governance Publishing: 122–127.
  18. ↑ Leybourn E. "Pair Trading: Collaboration in Finance". http://theagiledirector.com/content/pair-trading-collaboration-finance Retrieved 2015-03-30.
  19. ↑ Andersson R. and Bendix L. "Pair Teaching – an eXtreme Teaching Practice". "http://www.lth.se/fileadmin/lth/genombrottet/konferens2006/Insp06-final.pdf Retrieved 2015-03-30.

External links

  • wikiHow: How to Pair Program How-to guide; contains common wisdom on how to make pair programming work.
  • Codementor A marketplace of code mentors available for on-demand pair programming and long-term mentorship.
  • HackHands HackHands instantly connects developers with a network of expert programmers at the click of a button.
  • PairWithUs A collection of videos showing pair programming in action.
  • Airpair An online marketplace for finding expert programmers to pair with across a wide range of technologies.
Retrieved from "https://infogalactic.com/w/index.php?title=Pair_programming&oldid=16038"