Pair programming: Difference between revisions

Revision as of 20:58, 21 January 2023

Latest revision as of 20:51, 30 July 2025

(25 intermediate revisions by 15 users not shown)

Line 1:

{{short description|Collaborative technique for software development}}

[[File:Wocintech (microsoft) - 61 (25926639341).jpg|thumb|Pair programming]]

'''jfkl;adsf;dsaPair programming''' is a [[software development]] technique in which two [[computer programmer|programmers]] work together at one [[workstation]]. One, the ''driver'', writes [[Source code|code]] while the other, the ''observer'' or ''navigator'',<ref>{{cite conference |last1=Williams |first1=Laurie|author1-link=Laurie Williams (software engineer) |title=Integrating pair programming into a software development process |pages=27–36 |doi=10.1109/CSEE.2001.913816 |conference=14th Conference on Software Engineering Education and Training |date=February 19–20, 2001 |___location=Charlotte |isbn=0-7695-1059-0 |quote=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.}}</ref> [[code review|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 is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

==Economics==

Pair programming increases the [[man-hour|person-hour]]s required to deliver code compared to programmers working individually.<ref name="ijhcs"/> However, the resulting code has fewer defects.<ref name="costs-benefits"/> Along with code development time, other factors like field support costs and quality assurance also figure into the return on investment. Pair programming might theoretically offset these expenses by reducing defects in the programs.<ref name="costs-benefits">{{Cite journal|last1=Cockburn|first1=Alistair|last2=Williams|first2=Laurie|author2-link=Laurie Williams (software engineer)|title=The Costs and Benefits of Pair Programming|journal=Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)|author-link=Alistair Cockburn|year=2000|url=http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF|archive-date=2016-12-17|access-date=2007-11-05|archive-url=https://web.archive.org/web/20161217103943/http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF|url-status=dead}}</ref>

In addition to preventing mistakes as they are made, other intangible benefits may exist. For example, the courtesy of rejecting phone calls or other distractions while working together, taking fewer breaks at agreed-upon intervals, or sharedsharing breaks to return phone calls (but returning to work quickly since someone is waiting). One member of the team might have more focus and help drive or awaken the other if they lose focus, and that role might periodically change. One member might haveknow knowledge ofabout a topic or technique that the other does not, which might eliminate delays to findfinding or testing a solution, or allow for a better solution, thus effectively expanding the skill set, knowledge, and experience of a programmer as compared to working alone. Each of these intangible benefits, and many more, may be challenging to accurately measure but can contribute to more efficient working hours.{{citation needed|date=April 2022}}

==Design quality==

Line 15:

# the programmers bring different prior experiences to the task;

# they may assess information relevant to the task in different ways;

# they stand in different relationships to the problem by virtue of their functional roles.

In an 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.<ref>{{cite book |first1=Nick V. |last1=Flor |first2=Edwin L. |last2=Hutchins |chapter=Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance |pages=36–64 |chapter-url={{Google books|KT_bpSSJBgcC|page=36|plainurl=yes}} |editor1-first=Jürgen |editor1-last=Koenemann-Belliveau |editor2-first=Thomas G. |editor2-last=Moher |editor3-first=Scott P. |editor3-last=Robertson |year=1991 |title=Empirical Studies of Programmers: Fourth Workshop |publisher=Ablex |isbn=978-0-89391-856-9 }}</ref>

==Satisfaction==

In an online survey of pair programmers from 2000, 96% of programmers stated that they enjoyed workworking more while pair programming than programming alone. Furthermore, 95% said that they were more confident in their work when they pair programmed. However, as the survey was among self-selected pair programmers, it did not account for programmers who were forced to pair programsprogram.<ref name="strengthening">{{cite journal |last1=Williams |first1=Laurie|author1-link=Laurie Williams (software engineer) |last2=Kessler |first2=Robert R. |last3=Cunningham |first3=Ward |last4=Jeffries |first4=Ron |title=Strengthening the case for pair programming |journal=IEEE Software |volume=17 |issue=4 |year=2000 |pages=19–25 |doi=10.1109/52.854064 |url=http://sunnyday.mit.edu/16.355/williams.pdf |citeseerx=10.1.1.33.5248 }}</ref>

==Learning==

Knowledge is constantly shared between pair programmers, whether in the industry or in a classroom. Many sources suggest that students show higher confidence when programming in pairs,<ref name="strengthening"/> and many learn whether it be from tips on [[programming language]] rules to overall design skills.<ref name="support">{{cite journal |last1=Williams |first1=Laurie|author1-link=Laurie Williams (software engineer) |last2=Upchurch |first2=Richard L. |title=In support of student pair programming |journal=ACM SIGCSE Bulletin |volume=33 |issue=1 |year=2001 |pages=327–31 |doi=10.1145/366413.364614 |doi-access=free }}</ref> 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.<ref name="costs-benefits"/> Pair programming allows 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.<ref name="support"/>

==Team-building and communication==

Line 32:

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.

A [[meta-analysis]] found pairs typically consider more design alternatives than programmers working alone, arrive at simpler, more maintainable designs, and catch design defects earlier. However, it raised concerns that its findings may have been influenced by "signs of [[publication bias]] among published studies on pair programming"." It concluded that "pair programming is not uniformly beneficial or effective"."<ref name="hannay-meta">{{cite journal

| last = Hannay

| first = Jo E.

Line 44:

| doi = 10.1016/j.infsof.2009.02.001}}</ref>

Although pair programmers may complete a task faster than a solo programmer, the total number of [[man-hour|person-hour]]s increases.<ref name="ijhcs"/> 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, and for novices as compared to experts.<ref name='ijhcs'>{{cite journal

Line 81:

| archive-date = 2010-10-29

| url-status = dead}}</ref> It may reduce the code development time but also risks reducing the quality of the program.<ref name="hannay-meta"/> Productivity can also drop when novice–novice pairing is used without sufficient availability of a mentor to coach them.<ref>{{cite web|last=Stephens|first=Matt |author2=Doug Rosenberg |title=Will Pair Programming Really Improve Your Project?|url=http://www.methodsandtools.com/archive/archive.php?id=10| access-date = 28 May 2011}}</ref>

A study of programmers using AI assistance tools such as [[GitHub Copilot]] found that while some programmers conceived of AI assistance as similar to pair programming, in practice the use of such tools is very different in terms of the programmer experience, with the human programmer having to transition repeatedly between driver and navigator roles.<ref>{{cite journal |last1=Sarkar |first1=Advait |last2=Gordon |first2=Andrew D. |last3=Negreanu |first3=Carina |last4=Poelitz |first4=Christian |last5=Ragavan |first5=Sruti S. |last6=Zorn |first6=Ben |title=What is it like to program with artificial intelligence? |journal=Psychology of Programming Interest Group |date=2022 |url=https://www.ppig.org/papers/2022-ppig-33rd-sarkar/ |access-date=27 March 2023}}</ref>

==Indicators of non-performance==

There are indicators that a pair is not performing well: {{opinion|date=May 2021}}

* ''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.

Line 120 ⟶ 122:

* [[Extreme programming]]

* [[Joint attention]]

* [[MobTeam programming]] (also known as mob programming)

* [[TeamBody programmingDoubling]]

==References==