This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
"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)
The sentence in the intro describing the activity seems a bit weird ... "Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example." In my experience usually both programmers are working on the one task ... one is typing the code, and the other is helping to spot errors, for example. Maybe we should cite a source or two. Stumps 12:08, 22 May 2006 (UTC)
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)
This definitely needs more attention 89.17.137.199 (talk) 21:06, 12 September 2018 (UTC)
Is triple programming, quad programming, etc. also in common? --Abdull 17:06, 27 July 2006 (UTC)
triple programming (subjectively) seems to have both advantages and disadvantages compared to pair programming.
--68.0.120.35 22:09, 10 April 2007 (UTC)
When working at Microsoft, I was handed a very hard to reproduce bug. I worked on it for 3 days, but although the problem did show up, the code seemed to be fine. I put several hundred breakpoints and watched almost every variable and still everything seemed to be right, the function was called only at the right times, but still the behavior of the whole program was incorrect.
The bug had something to do with UTF-8. At some place, ASCII was being used and the buffer would get garbage. The problem reduced to "who was using the wrong API?" in which the wrong AP woudl be strcpy and the right API would be utf8_strcpy, but the main problem was that strcpy was used literally millions of times in appropiate places, so finding the explicit line with problem was going to take too much time.
One morning I saw my boss with his boss and the test leader all looking at one screen in my boss's office. They all were debugging the code and looking for places where this could have happened, and then they realized the problem was in a little DLL we were using and which we didn't have the source code. It took a lot of time!!!
So, the 3-programming went on but they weren't programming, but were debugging at one screen. I think even though they weren't programming this is a valid example, because debugging at Microsoft usually takes too much time. The main reason is that they still don't discover UnitTesting
So much human power was needed because of the lack of abstraction. if all tyou do is to call strcpy, then you will have strcpy all over the place and eventually your program will be hard to change.
— Preceding unsigned comment added by 201.241.19.29 (talk) 11:22, 8 July 2007 (UTC)
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)
* Experienced developers may find it tedious to tutor a less experienced developer in a paired environment.
but isn't it more tedious to let that developer loose on her own and deal with the mess later? with pp-style tutoring, that developer may well become an experienced and talented developer in time
* A less experienced developer may feel intimidated pairing with a more experienced developer which may result in less participation. * Many engineers prefer to work alone, and may find the paired environment cumbersome.
isn't this sort of a circular argument, with "prefer" depending on some actual or percieved drawbacks?
* Productivity gains or losses are hard to compare between paired and non-paired environments, as metrics of programmer productivity are controversial at best.
weird phrasing, and is this really a drawback of pp?
* Experienced engineers quite likely produce code that is quite accurate, and the additional theoretical gain from pairing might not be worth the cost of an additional engineer. This is especially true when producing more trivial parts of the system.
dict "quite likely"
* Differences in coding style may result in conflict.
again, better to deal with this upfront than later.
* In the case where the team has slightly different work schedules, which is common in an environment that values work-life balance, the pair is only available during the overlap of their schedules. Therefore, not only does it require more man-hours to complete a task, a typical day has fewer pair-hours available, which further increases the overall task completion time. * Where a company values telecommuting (working from home) or when an employee must work from outside the office for whatever reasons, pair programming can be difficult and even impossible. However with broadband internet access and common screen sharing programs and VOIP technologies such as Skype, telecommuting can in fact better lend itself to pair programming. (see Remote pair programming) * Personality conflicts can result in one or both developers feeling awkward or uncomfortable. * Some developers can sit in front of a computer for many hours straight, others like to get up and walk around often.
that's fine; either take breaks often or just stand up and walk while the other person drives —Preceding unsigned comment added by 193.11.12.233 (talk) 12:15, 26 October 2007 (UTC)
?? Where is the drawbacks list? there seems to be no counterpoint in this article. 20:59, 1 December 2014 (UTC)jflahiff — Preceding unsigned comment added by 69.25.143.32 (talk) 20:58, 1 December 2014 (UTC)
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)
How about extracting the quotes into a Notes section, using shortened footnotes (Citing Sources style guide)? The Williams quotes are well researched, but currently, the other references are somewhat drowned out. — Preceding unsigned comment added by 85.166.140.106 (talk) 20:11, 21 July 2008 (UTC)
All of the actual scientific, peer-reviewed studies I've read on pair programming have found no benefit to experienced programmers, only to students. This article is very heavily biased based on programmers self-reported _impressions_ and _feelings_ regarding the benefits, instead of the actual lines of code and quality of the code produced. Of course pair programming makes most programmers feel better about coding- coding is, like writing in general, a lonely, cognitively-rich task, and pairing makes it much less lonely- but that doesn't mean that it makes the output better. 173.228.123.235 (talk) 11:09, 6 November 2011 (UTC)
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)
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)
* 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)
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)
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)
Snipped the following section:
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)
References
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)
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)
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)
[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)
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)
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)
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)
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)
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)
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)
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)
In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone.
In an online survey of pair programmers, 96% of them stated that they enjoyed their work more when paired than when they programmed alone.
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)
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)
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)