|
==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 in tointo 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}}</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 shared 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 have knowledge of a topic or technique whichthat the other does not, which might eliminate delays to find or testtesting 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==
==Satisfaction==
In an online survey of pair programmers from 2000, 96% of programmers stated that they enjoyed work 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 programprograms.<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 skillskills.<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==
|
