Talk:Pair programming

message: "Pair programming is an agile software development technique in which two programmers work together at one workstation."
This is not correct as the two programmers can be collaborating from different locations. Even if they are co-located  using separate workstations and communicating by voice or phone may be more efficient.Danwoodard (talk) 18:42, 19 January 2020 (UTC)
replies: text: Which sources do you have that says the they should do the same thing? People commenting on you drivings is not a help but people reading the map and tell you which way to go is a great help. --Equanimous2 17:45, 19 September 2006 (UTC)

text: I agree.  "One types in unit tests while the other thinks about the class..." is just wrong.  The whole point of pair programming is continuous code review.  I'll fix it right now.  I don't have books handy, but I think finding citations will be easy.  (A quick Google search turns up plenty.) --Ben Kovitz 21:45, 5 November 2007 (UTC)
thread_title:  Complaint about intro 

message: The Utah study quoted in the article gives attribution to Laurie Williams, but the coauthor of the study was Alistair Cockburn, one of the signatories to the Agile Manifesto -- hardly a disinterested party!  
— Preceding unsigned comment added by 66.194.74.34 (talk) 17:59, 2 June 2006 (UTC)
thread_title:  Utah study attribution 

message: Pair Programming Productivity: Novice-novice vs. Expert-expert International Journal of Human Computer
... this link gives you a 404.  
— Preceding unsigned comment added by LukeCrawford (talk • contribs) 07:59, 6 May 2007 (UTC)
thread_title:  bad link 

message: Did Laurie Williams write most of this article or sanction it?  Most of the cites are quotes from her books and studies.  And much of that is suspicious, such as "In our recent Web survey, we asked, 'What have you found beneficial about pair programming?' The single most common response was, 'It's a lot more fun!'"  This is scientific?  Sounds like it was probably a web survey of a pro-Pair Programming group.76.168.64.243 (talk) 19:33, 4 May 2008 (UTC)
replies: text: Nope, I put most of those references in. I believe Laurie Williams has been the leading researcher on pair programming.  If you have more good sources, please add 'em! Ben Kovitz (talk) 08:36, 10 May 2008 (UTC)

text: I just changed the references to a 2-column format. Does that help? I couldn't figure out how to do shortened footnotes and still keep all the quotations intact. I'd like to keep the quotations so it's easy for readers to quickly check the substance of the reference and make objections like the one above. --Ben Kovitz (talk) 04:07, 18 February 2009 (UTC)
thread_title:  Laurie Williams? 

message: How about extracting Remote pair programming into a separate article? The External links and References are somewhat cluttered now, particularly the list of tools for remote pair programming.  —Preceding unsigned comment added by 85.166.140.106 (talk) 20:11, 21 July 2008 (UTC)
thread_title:  Extract Remote pair programming into separate article? 

message: Some external links seem to have worked their way into the See Also section.  I'm not really sure how they got away with it as I don't actually see any URLs in the raw text.  I'm not sure how this should be dealt with, but at least I've brought it up. Isarl (talk) 02:35, 10 October 2009 (UTC)
thread_title:  External links in See Also section 

message: * Programmers can engage in over-analysis
I can't back this up with a research link, but I'm sure you'll agree that this is a common problem with pairing, especially with verbose types who need to make their opinion heard.  I've had whole pair programming sessions wasted with stupid conversations.  You can say it can be avoided, but introducing a social aspect to programming does have this inherent drawback of unnecessary conversation.
Erichero (talk) 08:28, 22 December 2009 (UTC)
replies: text: Sounds like  original research. There have been a lot more studies of pair programing in the last few years. If you can find one that describes this, by all means, put it in. If you can find studies that measure the effect on time to completion, that would be especially good, since that's the bottom line of interest. —Ben Kovitz (talk) 03:16, 14 June 2010 (UTC)

text: The entire drawbacks section appears to be missing...  — Preceding unsigned comment added by 205.221.255.62 (talk) 16:28, 14 January 2014 (UTC)
thread_title:  Additional drawback 

message: I'm now phasing out the section listing scientific studies, and moving the quantitative results and references to the "Costs and benefits" section. There are still some duplicate studies, because I don't want to lose the quantitative information and references, and I haven't gotten access to all the references. In particular, I'm hoping to see the "Costs and benefits" section summarize the findings regarding defect rates, time to completion, and total effort. That will make the article very useful to readers interested in what is known about pair programming. If anyone else would like to help gather up this info and put it into "Costs and benefits", please don't be bashful! —Ben Kovitz (talk) 03:25, 14 June 2010 (UTC)
thread_title:  Phasing out "Scientific studies" section 

message: Not being a researcher in this field, or a programmer, I have no idea what effort means when it comes to programming? Pay? Physical effort? Mental effort?  — Preceding unsigned comment added by TheThomas (talk • contribs) 11:55, 11 December 2010 (UTC)
replies: text: Excellent question. As defined in the paper by Arisholm, et al., effort is total programmer-hours. I'll add that to the article right now. —Ben Kovitz (talk) 19:23, 16 March 2011 (UTC)
thread_title:  What does effort mean in all this? 

message: 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.[Software, IET|http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4595506&tag=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)
thread_title:  "The fusing of pair and solo programming" 

message: 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)
replies: text: 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)
thread_title:  Marketing Spin or Technical Accuracy? 

message: 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)
replies: text: 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)
thread_title:  Please help explain 

message: [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)
replies: text: Free preprints are useful, but not required see WP:PAYWALL. Tijfo098 (talk) 21:03, 18 November 2012 (UTC)
thread_title:  IEEE Citations only available to IEEE members 

message: 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)
replies: text: Done. —Ben Kovitz (talk) 14:12, 26 May 2012 (UTC)
thread_title:  Reference doesn't support Ping Pong Pair Programming claim 

message: 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)
thread_title:  There seems to be an error 

message: 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)
replies: text: 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)
thread_title:  Miscellaneous questions 

message: 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)
thread_title:  No costs 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Neutrality 

message: 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)
replies: text: 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)
thread_title:  Replication (not in cited article) 

message: 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)
replies: text: 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)
thread_title:  Impersonal and dehumanizing 

message: Tiny nit. The plural of "code" is not "codes" in this situation. 
Thomaso (talk) 15:33, 18 February 2014 (UTC)
thread_title:  Nit: Plural of "code" is not "codes" 

message: 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)
thread_title:  Correlation is not causality 

message: 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)
thread_title:  Pairing variations oddity 

message: 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)
thread_title:  * Experienced developers may find it tedious to tutor a less experienced developer in a paired environment. 

message: 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)
replies: text: .  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)
thread_title:  "Worse still, the expert may simply withdraw their labor" 

message: 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)
replies: text: 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)
thread_title:  "Novice-novice Pairing is not recommended" 

message: 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)
thread_title:  "promiscuous pairing" 

message: 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)
thread_title:  Indicators of non-performance = opinion?