Talk:Pair programming

Snipped the following section:

The role of pair programming in software development is controversial. This is due partly to the relatively unclear benefit of pair programming over solo programming. There have been arguments either way and there have been studies to show that one is more cost-effective than the others. Rather than investigating into pair vs. solo programming here, a new process model was created which combined both together. The fusing of pair and solo programming processes may actually be better than adopting either alone. In the proposed model, a donor and a recipient process can be defined and if some transfer conditions are met, one process can be converted into another to achieve tasks with minimal costs. The fusing of pair and solo programming can be a more effective approach to increase productivity of less experienced programmers.^[1]

After reading it, I'm skeptical that it belongs in Wikipedia at all; it reads more like a new proposal than a description of something that exists. I haven't read the source, but I'm guessing it's a scholarly argument in favor of the technique rather than a description of something already in use. I could see mention of this being appropriate in the article if it were described as an untested idea that someone had rather than a proposition being made by Wikipedia. --Brilliand (talk) 19:13, 28 February 2011 (UTC)

What is the purpose of the article? Content sounds too subjective. The most specific, technically accurate definition is "two people working together, at a single terminal". In the 1980s this was called "working together" and was typically limited to academia. Kernel.package (talk) 13:56, 15 March 2011 (UTC)

It's more specific than that. The main idea is continuous (line-by-line) code review. Of course, many other things happen in addition to code review when one person sits and watches the person whose code they're reviewing. If you're interested, please read the article and look into some sources, and you may find a way to make the article more informative. —Ben Kovitz (talk) 19:08, 16 March 2011 (UTC)

I am a Wikipedian and contribute to zh.wp, I am translating the article to Chinese, but I cannot understand the "The benefit is strongest on tasks that are not yet understood by the programmers, calling for more creativity, challenge, and sophistication", I am not sure which meaning of sophistication should use. Thanks in advance. --Yongxinge(talk) 13:22, 23 March 2011 (UTC)

Hi, Yongxinge. I tried rewriting the sentence to be clearer, but I'll try explaining more here. (Maybe someone else can improve the English version, too.) The idea is that pairing does the most good, in comparison to each programmer working solo, when the problem to be solved is difficult because it's not fully understood by the programmers when they start. By pairing, they spur each other's creativity and help define the problem better. Working solo, a programmer typically has a harder time understanding the problem, works for longer, and doesn't come up with as appropriate a solution. By contrast, pairing is less beneficial, in comparison to working solo, on routine problems that are already familiar to the programmers. For example, changing all occurrences of a certain string literal in a program is not a likely task where pairing will do much good. But figuring out a deep bug that no one understands yet is likely to go much better with pairing. (In fact, people often "pair" on debugging without ever having heard of pairing, since the difficulty of the problem clearly calls for two people to work together. The interesting idea of pairing as described in the article is that it can help even when writing new code, although then it requires a little more discipline.) Does that help? —Ben Kovitz (talk) 04:20, 19 April 2011 (UTC)

Yujunliang has posted a pic in this version with the caption, "While hardware becoming relatively cheap these days, a new setup with two monitors sharing one workstation became more popular in the industry." Is this true? Are there sources that establish this? My understanding of pair programming is that: (a) the expense of hardware was never a concern, even in the earliest days: usually each programmer had a separate workstation, anyway, but when pairing, they worked at just one workstation; (b) pairing loses a lot of its effectiveness when both programmers are not looking at the same screen or when both programmers have access to keyboards (because the programmers stop reviewing each other's work and stop explaining out loud what they're doing). That's mostly from personal experience, although the sources I've seen nearly always speak of two programmers at one workstation, and the cost of programmer time has always been seen as the leading drawback of pairing, not the cost of the workstations. Has there been a big change? —Ben Kovitz (talk) 04:04, 19 April 2011 (UTC)

Hi Ben,

To answer your question, this picture was taken in the office of my client, a financial company in Dallas. Please look closer, the two monitors display the same content. They are connected to the same workstation via signal splitter. This setup solved the problem of making two developers staying too close to each other. I can provide more detail about the setup if you are interested. Sorry for the confusion earlier. — Preceding unsigned comment added by Yujunliang (talk • contribs) 00:54, 20 April 2011 (UTC)

Thanks for telling me how you got the picture, Yunjunliang. It sounds like your client is doing an interesting experiment. Is it original research, though? Is pairing with separate keyboards and monitors typical in industry now, or is it something unusual? If it has become typical (contrary to the sources now used for the article, which are several years old), are the any sources to verify this? —Ben Kovitz (talk) 16:51, 20 April 2011 (UTC)

This is the normal setup from the company I work for, ThoughtWorks Inc. But we are not alone, please see the setup in this blog entry,

http://devblog.point2.com/tag/intellij/

— Preceding unsigned comment added by Yujunliang (talk • contribs) 03:05, 21 April 2011 (UTC)

Sorry to take so long to get back to this thread! Unfortunately, it sounds like the picture does not do a good job representing common practice. Doing this at one or two companies doesn't make it the ordinary practice, and a blog post without editorial oversight is not a reliable source. The pic is of poor quality: the composition is poor, and it doesn't clearly illustrate pair programming or even the specific variant of pair programming that you've described. An improved pic of the same thing wouldn't help, because of all the other problems I noted above, which you didn't address. So, I'm deleting the picture. Please don't add it back. —Ben Kovitz (talk) 01:33, 7 August 2011 (UTC)

[1] an IEEE citation is only available to IEEE members. It is unlikely anyone outside of IEEE members will be able to read this. A freely available Internet citation is needed. Johnswolter (talk) 14:02, 12 September 2011 (UTC)

Free preprints are useful, but not required see WP:PAYWALL. Tijfo098 (talk) 21:03, 18 November 2012 (UTC)

The reference to http://www.c2.com/cgi/wiki?PairProgrammingPingPongPattern does not support or deny the claim that "In general, this approach may take more time than the estimated plan." Seems like the reference should be nixed. — Preceding unsigned comment added by 76.191.142.169 (talk) 14:23, 28 October 2011 (UTC)

Done. —Ben Kovitz (talk) 14:12, 26 May 2012 (UTC)

Pairs usually complete work faster than one programmer assigned to the same task.
&
Even though coding is often completed faster than when one programmer works alone, total programmer time (number of programmers × time spent) increases.
Are contradictory, one claims pairs are faster and the other claims solo is faster, I believe the intention in the second sentence was: Even though coding is often completed faster than when two programmers work together, total programmer time (number of programmers × time spent) increases. as this also seems to make more sense, due to the first version being redundant and, well wrong, I don't really know how to explain. 193.105.7.54 (talk)

I don't think the two sentences contradict each other, and both are correct, but the distinction is a little subtle: less calendar time, but more total programmer-hours. Someone else brought up the same confusion in the section "What does effort mean in all this?", above. You are more than welcome to clarify and improve the wording. —Ben Kovitz (talk) 14:24, 26 May 2012 (UTC)

Anybody with a miscellaneous question, please place it here.

What is the prevalence of pair programming? I mean, how much is it used?CountMacula (talk) 18:52, 3 September 2012 (UTC)

The way we practiced pair programming involved a continuous shifting around of the programmers, shifting partners every half day of every day. There is no mention of this at all. Using this variation of pair programming had one major additional benefit: all team members were far more strict on enforcing the coding rules they imposed on themselves, since they would be required to add functionality to code they had not ritten themselves. — Preceding unsigned comment added by 2A02:1811:E409:BF00:F4B0:7825:F594:FD14 (talk) 10:33, 9 March 2015 (UTC)

Why are there no costs listed in the "Costs and Benefits" section in the introduction? The section implies there is not a single drawback, as everything here is positive. — Preceding unsigned comment added by 137.71.23.54 (talk) 16:20, 26 November 2012 (UTC)

I've added the neutrality template to this article. It only includes advantages to this development method while the language reads almost like a sales pitch in some areas. Furthermore, the first 13 sources (more than half of the total) were written by the same author, most of which in the same publication. It looks as though the references count has been artificially inflated by counting each page of the same references as a separate reference entirely.

Concern was also raised here by another user about the fact that the "Costs and Benefits" section only contains benefits. That concern has never been addressed or even discussed since it was raised three months ago.

Because of the extremely poor quality of the article's citations and rather blatantly biased perspective, I've decided to add a couple other relevant templates as well. Please do not remove them until the issues raised here have been resolved. Some parts of the article may need to be rewritten so that they're not relying almost exclusively on a single source. KrisCraig (talk) 03:23, 1 February 2013 (UTC)

More than a year later, it's more and ad - or perhaps better stated, an advocacy piece - than an article. — Preceding unsigned comment added by 68.183.37.170 (talk) 20:57, 21 May 2014 (UTC)

It's essentially an enthusiast's page: who has time for another edit war? The studies never seem to cover the practicalities that would make up a real list of objections, anyway: do you like sitting for days on end nestled in conversation with someone you are not married to? Do you enjoy having someone chew with an open mouth into your ear or idly pick their nose two feet from your face? Are you incapable of reaching that fragile headspace where you juggle the machine state in your head? Why not indulge in pair programming? I'm only mildly exaggerating. Endie (talk) 21:36, 16 June 2014 (UTC)

An Article by Giri and Soni is being cited as a reference for experimental replication that pair programming is effective. This article does not provide such evidence.

Some quotes from an article being cited as evidence for replication: "This experiment was carried out on students for learning purposes; therefore the experiment was not strictly monitored." and in the Conclusion: "The primary contribution of this study is to provide an overview of Pair Programming and to demonstrate the use of Programming Aptitude Test in the aspect of pair generation or team building that facilitates to make pair of newly hired programmers in an industry." Derek farn (talk) 12:10, 26 November 2013 (UTC)

In the section 2, the authors replicated the horse-trading system on their own in the background section, and the authors achieve the same results as quoted previously. — Preceding unsigned comment added by Hzhbcl (talk • contribs) 12:20, 26 November 2013 (UTC)

Hzhbcl, To regard this work as a viable replication is clutching at straws. The authors of the paper don't claim that it is a valid replication and explicitly point out it was done for learning purposes and not monitored. Why are you so desperately for this to be a replication? Derek farn (talk) 15:32, 26 November 2013 (UTC)

Is there going to be any mention of how impersonal and dehumanizing p.p. can be? Any two random people in the West are likely to have vastly different work habits, and prolonged p.p. is going to make them hate each other. It goes against the grain of individual independence and freedom. Ever see two painters painting the same canvas? Two cooks making the same soup? Two equal drivers in a car? No, no, and no. I urge managers worldwide to stay away from or at least never enforce this hideous methodology. Collaboration and feedback are undoubtedly essential, but p.p. takes it to the extreme, and the extreme is always a dangerous place to be. When I'm programming, I like to be lost in my thoughts, think a problem through, feel that light bulb turn on, explore and experiment, and not be yapping with anybody else. Unless my pair is a 10/10 fine 6ft blonde, in which case I'll also be exploring and experimenting with her, I would rather be left to pair with myself. Remember, programmers are typically much more introverted than extroverted. --IO Device (talk) 23:48, 3 January 2014 (UTC)

Thank you with every cell in my body for writing this, a fellow programmer! And I am not typically introverted as a person, but when I have to analyze difficult stuff, I like to have a little bit of peace and quiteness on my own. That is a capital crime to some p.p. zealots. I also seriously doubt this quoted survey were they stated that 95% of the programmers loved pair programming. Internet polls can be very biased. — Preceding unsigned comment added by 147.108.61.93 (talk) 10:20, 3 April 2016 (UTC)

Tiny nit. The plural of "code" is not "codes" in this situation.

Thomaso (talk) 15:33, 18 February 2014 (UTC)

😂 21:09, 12 September 2018 (UTC) — Preceding unsigned comment added by 89.17.137.199 (talk)

In the Benefits section, it states "A correlation exists between satisfaction among programmers and their confidence in the codes i.e. the pairs enjoy their work more because they are more confident in it.". I do not have access to the referenced paper, but based on the text at hand, this is an invalid conclusion. Correlation between two things does not necessarily mean that one was caused by the other. (It would perhaps be correct to change this to "it may be that the pairs enjoy their work more because they are more confident in it.") -- Foogod (talk) 20:53, 10 March 2014 (UTC)

What does 'However this can sometimes lead to "watch the master" or if the novice feels it has nothing to add and being a burden, it can start to clear one's throat to get more time to think when asked a question.' mean? To call the novice 'it' is at best impolite, and 'it can start to clear one's throat' is bad grammar. 86.166.164.33 (talk) 17:37, 11 March 2014 (UTC)

I tried to understand the obscure meaning and fix the awkward sentences,50.150.41.74 (talk) 09:58, 19 December 2014 (UTC)

This can not be under emphasised. The reality is that handing junior ( and probably juvenile and incompetent ) coders to sit next to expert engineers is just plain wrong. Putting an incompetent engineer into a project reduces production efficiency and quality while increasing project risk. It also incentives very talented engineers to leave employment — Preceding unsigned comment added by 85.199.231.18 (talk) 13:09, 17 April 2015 (UTC)

"In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone."

"In a survey of mountain bikers, 96% of them stated that they preferred mountain biking to sitting at home on the couch." 208.65.73.219 (talk) 21:54, 5 November 2015 (UTC)

Might we rephrase this:

In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone.

...to:

In an online survey of pair programmers, 96% of them stated that they enjoyed their work more when paired than when they programmed alone.

When I read the original text in the article just now, I misunderstood it, due to the phrasing.

-- Tomz0rs (talk) 01:19, 17 November 2015 (UTC)

The description of "Expert-novice" pairing mentions that "Worse still, the expert may simply withdraw their labor and get employment elsewhere." Why is this especially relevant to expert-novice pairing, as opposed to any other pairing or indeed any other workplace scenario? Does expert-novice pairing somehow encourage experts to withdraw their labor or make it especially damaging for them to do so? Should we go ahead and add the caveat "employees sometimes quit" to every other description of a business practice? 24.227.125.115 (talk) 17:52, 25 August 2016 (UTC)

 Done. I removed "expert withdraw" comment; besides the above issue, this isn't in the source cited. I added a comment on expert patience required, which is in the source. Thanks for catching this. --A D Monroe III (talk) 20:39, 25 August 2016 (UTC)

This claim is not supported in the paper provided as a citation. — Preceding unsigned comment added by 129.93.4.25 (talk) 16:55, 31 August 2017 (UTC)

While this might be inappropriate in the university context as it might be classified as collusion, in more generic context there is no reason for it to be discouraged. I suggest "(university)" to be removed from the title and added within the body of the text as an exception.--2A02:C7D:DA27:BA00:3995:F80:5EBD:99AF (talk) 15:01, 24 June 2018 (UTC)

I've removed the word 'university' as it makes very little sense. I haven't added it to the body as an exception. When I was a student and later an instructor pair programming was encouraged on programming assignments and the grade was shared. Martijn Meijering (talk) 16:35, 27 October 2018 (UTC)

The paper cited has a single brief line on mixing teams, in the team-building and comm section:

Rotating partners increases the overall information flow farther.

Leaving aside any larger discussion of politeness, "promiscuous pairing" isn't supported (or even mentioned) by the source. -- Shannon Garcia (talk) 21:57, 16 November 2017 (UTC)

I can't find any sources for these indicators of non-performance. I flagged them as possibly being someone's opinion. 81.170.128.52 (talk) 15:41, 14 May 2021 (UTC)

Hello, I’d like to suggest a small addition to the Remote pair programming section to support the importance of low latency in collaborative programming environments. [https://gethopp.app/blog/latency-exploration#:~:text=Remote%20control%20demands%20minimal%20delays%20for%20a%20seamless%20experience%2C%20with%20Apple%20noting%20that%20delays%20over%20100%20ms%20in%20the%20UI%20disrupt%20smooth%20interactions. Per Apple’s guidance that delays over 100ms] can noticeably disrupt smooth UI interactions—something highly relevant when using remote control or screen sharing tools for pair programming.

The post at the blog I posted, is a fair break down on why latency matters in remote pair programming, but also what accounts in latency in modern computers. Konsalex (talk) 18:36, 22 June 2025 (UTC)

Wikipedia doesn't use self published blogs and such as sources, see WP:RS. - MrOllie (talk) 18:57, 22 June 2025 (UTC)

a online shop for evry thing ~2026-11815-15 (talk) 21:03, 21 February 2026 (UTC)