{"id":5003277,"date":"2015-12-16T23:20:34","date_gmt":"2015-12-17T07:20:34","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003277"},"modified":"2023-03-08T15:58:52","modified_gmt":"2023-03-08T23:58:52","slug":"pair-programming","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/pair-programming\/","title":{"rendered":"Pair Programming"},"content":{"rendered":"<div>\n<div>\n<p>Pair programming consists of two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair). The programmer at the keyboard is usually called the \u201cdriver\u201d, the other, also actively involved in the programming task but focusing more on overall direction is the \u201cnavigator\u201d; it is expected that the programmers swap roles every few minutes or so.<\/p>\n<h2>Also Known As<\/h2>\n<p>More simply \u201cpairing\u201d; the phrases \u201cpaired programming\u201d and \u201cprogramming in pairs\u201d are also used, less frequently.<\/p>\n<h2>Common Pitfalls<\/h2>\n<ul>\n<li>both programmers must be actively engaging with the task throughout a paired session, otherwise, no benefit can be expected<\/li>\n<li>a simple but often raised objection is that pairing \u201cdoubles costs\u201d; that is a misconception based on equating programming with typing \u2013 however, one should be aware that this is the worst-case outcome of poorly applied pairing<\/li>\n<li>at least the driver, and possibly both programmers, are expected to keep up a running commentary; pair programming is also \u201cprogramming out loud\u201d \u2013 if the driver is silent, the navigator should intervene<\/li>\n<li>pair programming cannot be fruitfully forced upon people, especially if relationship issues, including the most mundane (such as personal hygiene), are getting in the way; solve these first!<\/li>\n<\/ul>\n<h2>Origins<\/h2>\n<p>The names of various celebrities have been invoked in an attempt to imbue pair programming with an aura of necessity if not sanctity; anecdotes of John Von Neummann, Fred Brooks, Jerry Weinberg, Richard Gabriel or&nbsp;<a href=\"http:\/\/c2.com\/cgi\/wiki?DijkstraPairProgramming\">Edsger Dijkstra<\/a> using the practice is fascinating but sometimes hard to substantiate. However, the following timeline of verifiable sources does suggest that pair programming, in its modern form, has been around since well before the Agile movement:<\/p>\n<ul>\n<li>1992: \u201cDynamic Duo\u201d is the term coined by Larry Constantine, reporting on a visit to Whitesmiths Inc., a compiler vendor started by P.J. Plauger, one of the implementors of C: \u201cAt each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.\u201d Whitesmiths existed from 1978 to 1988.<\/li>\n<li>1993: \u201cThe benefits of collaboration for student programmers\u201d by Wilson et al. is one early empirical study indicating the benefits of pairing for programming tasks specifically. Posterior studies are more abundant and driven by the desire to \u201cvalidate\u201d pair programming after it had already gained popularity through <a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">Extreme Programming<\/a>.<\/li>\n<li>1995: the pattern \u201cDeveloping in Pairs\u201d is given a brief description, in&nbsp;<a href=\"http:\/\/c2.com\/cgi\/wiki?AlexandrianForm\">Alexandrian<\/a>&nbsp;pattern form, in Jim Coplien\u2019s chapter \u201cA Generative Development-Process Pattern Language\u201d from the first patterns book, \u201cPattern Languages of Program Design\u201d.<\/li>\n<li>1998: in \u201cChrysler goes to Extremes\u201d, the earliest article about Extreme Programming, pair programming is presented as one of the core practices of the C3 team; it is later described formally as one of XP\u2019s original \u201ctwelve practices\u201d<\/li>\n<li>2000: (or earlier) \u2013 the roles of Driver and Navigator are introduced to help explain pair programming; the earliest known reference is a&nbsp;<a href=\"http:\/\/tech.groups.yahoo.com\/group\/extremeprogramming\/message\/12405\">mailing list posting<\/a>; note however that the reality of these roles has been disputed, for instance, Sallyann Bryant\u2019s article \u201c<a href=\"http:\/\/www.sciencedirect.com\/science\/article\/pii\/S1071581907000456\">Pair programming and the mysterious role of the navigator<\/a>\u201c<\/li>\n<li>2002: \u201c<a href=\"http:\/\/www.amazon.com\/dp\/0201745763\">Pair Programming Illuminated<\/a>\u201c, by Laurie Williams and Robert Kessler, is the first book devoted exclusively to the practice and discusses its theory, practice, and the various studies up to that date<\/li>\n<li>2003: an anonymous article on the C2 Wiki describes&nbsp;<a href=\"http:\/\/www.c2.com\/cgi\/wiki?PairProgrammingPingPongPattern\">Ping-Pong Programming<\/a>, a moderately popular variant that marries pairing with test-driven development.<\/li>\n<li>2015: James Coplien publishes&nbsp;<a href=\"https:\/\/computingnow.computer.org\/web\/agile-careers\/content?g=8504655&amp;type=article&amp;urlTitle=two-heads-are-better-than-one\" target=\"_blank\" rel=\"noopener noreferrer\">Two Heads are Better Than One<\/a> which provides an overview of the history of Pair Programming that traces its origins back to the mid 1980s if not before.<\/li>\n<\/ul>\n<h2>Skill Levels<\/h2>\n<p>As suggested above one of the major issues preventing effective pairing is passivity. When used simultaneously with&nbsp;<a href=\"https:\/\/agilealliance.org\/glossary\/tdd\/\">test-driven development<\/a>, one variant called \u201cping-pong programming\u201d encourages more frequent switching of roles: one programmer writes a failing unit test, then passes the keyboard to the other who writes the corresponding code, then goes on to a new test. This variant can be used purely for pedagogic purposes, or by already experienced programmers as a playful variant.<\/p>\n<ul>\n<li>Beginner:<\/li>\n<li>able to participate as navigator, in particular, to intervene appropriately<\/li>\n<li>able to participate as a driver, in particular, to explain code while writing it<\/li>\n<li>Intermediate<\/li>\n<li>can tell the right moment to give up the keyboard and switch roles<\/li>\n<li>can tell the right moment to \u201csteal\u201d the keyboard and switch roles<\/li>\n<li>Advanced<\/li>\n<li>able to \u201cdrop in\u201d when another pair has been working on a task and pick up the navigator role smoothly<\/li>\n<\/ul>\n<h2>Signs Of Use<\/h2>\n<ul>\n<li>the room\u2019s furniture and workstations are set up so as to encourage pairing (in teams new or hostile to pairing, obvious mistakes are tolerated, such as desks with too little room for two chairs)<\/li>\n<li>the room\u2019s noise level is controlled: the muted conversations from several simultaneous pairs create a background hum but do not rise to the level where they would disturb anyone\u2019s work<\/li>\n<li>if, on entering the room, you spot any programmer wearing an audio headset, take that as a \u201cnegative\u201d sign \u2013 not only is pairing probably not practiced in the team but the conditions for successful adoptions are likely not met<\/li>\n<\/ul>\n<h2>Expected Benefits<\/h2>\n<ul>\n<li>increased code quality: \u201cprogramming out loud\u201d leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys<\/li>\n<li>better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is paired with one who knows it much better<\/li>\n<li>better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members<\/li>\n<li>large reduction in coordination efforts, since there are N\/2 pairs to coordinate instead of N individual developers<\/li>\n<li>improved resiliency of a pair to interruptions, compared to an individual developer: when one member of the pair must attend to an external prompt, the other can remains focused on the task and can assist in regaining focus afterward<\/li>\n<\/ul>\n<h2>Potential Costs<\/h2>\n<p>While empirical studies have yet to yield definite results on either benefits or costs, a commonly cited best-case estimate of 15% overhead is claimed for systematic pairing, relative to individual work; this overhead, it is claimed (again with some empirical support, though not entirely conclusive), is compensated by gains in code quality which usually entails significant maintenance penalties down the road.<\/p>\n<h2>Academic Publications<\/h2>\n<p>Theoretical<\/p>\n<ul>\n<li>Among the more interesting theoretical papers are those pursuing the ethnographic approach initiated among others by Sallyann Freudenberg (n\u00e9e Bryant), using a close examination of programmers in their day-to-day work:<\/li>\n<li><a href=\"http:\/\/www.scribd.com\/doc\/25304465\/\">How Pair Programming Really Works<\/a>&nbsp;surveys some of the work that has attacked the \u201cdriver\/navigator\u201d distinction<\/li>\n<\/ul>\n<p>Empirical<\/p>\n<ul>\n<li><a href=\"http:\/\/collaboration.csc.ncsu.edu\/laurie\/Papers\/dissertation.pdf\">The Collaborative Software Process<\/a>, Laurie Williams\u2019 doctoral thesis, among the better-known studies on the topic, reports increased quality and no statistically significant cost overhead<\/li>\n<li><a href=\"http:\/\/www.idi.ntnu.no\/grupper\/su\/publ\/ebse\/R11-pairprog-hannay-ist09.pdf\">The effectiveness of pair programming: A meta-analysis<\/a>, surveying 18 major empirical studies, reporting increased quality and compressed schedules, but some cost overhead; schedule compression mainly for simpler tasks performed by junior developers, a situation which also correlates with lower quality<\/li>\n<li>Most empirical studies (14 out of the above-mentioned 18) suffer from one common flaw often cited as an obstacle to generalizing conclusions: they are conducted with \u201cconvenience samples\u201d of graduate or undergraduate students rather than on professionals in realistic work conditions<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<div>\n<div><\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the &#8220;driver&#8221;, the other, also actively involved in the programming task but focusing more on overall direction is the &#8220;navigator&#8221;; it is expected that the programmers swap roles every few minutes or so.<\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[859],"class_list":["post-5003277","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology","tag-xp"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003277","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003277"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003277\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003277"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003277"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003277"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}