[rileymat2]

It has always been strange to me that for an industry that claims to be engineering and data focused stops when it comes to our own processes.

One Lazy google search searching for a paper, and not a blog:

https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia....

  In 1999, a controlled experiment run by the
  second author at the University of Utah
  investigated the economics of pair programming.
  Advanced undergraduates in a Software
  Engineering course participated in the
  experiment. One third of the class coded class
  projects as they had for years – by themselves.
  
  The rest of the class completed their projects with
  a collaborative partner. The results of how much
  time the students spent on the assignments are
  shown below in Figure 1. After the initial
  adjustment period in the first program (the
  “jelling” assignment), together the pairs only
  spent about 15% more time on the program than
  the individuals [4]. Development costs certainly
  do not double with pair programming!

  Significantly, the resulting code has about 15%
  fewer defects [4]. (These results are statistically
  significant.) Figure 2 shows the postdevelopment 
  test cases the students passed for
  each program – essentially the percentage of the
  instructor’s test cases passed.

  The initial 15% increase in code development
  expense is recovered in the reduction in defects,
  as the following example illustrates...

So the from this paper is the initial work is more costly, anyone that tells you it is not is probably wrong, but not double. But they are producing different work at a different quality level, at a different speed.

Sure there could be problems with the methodology, it might apply to students and not professionals (a classic psyche 101 bias). But it is something, certainly not a scam.

[nonameiguess]

Not gonna say it's a scam, but it's quite a stretch to call this science. Your paper only has this snippet about this experiment at the University of Utah. The actual paper about that experiment is here: https://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftwar.... It's not a real paper. It's a non peer-reviewed submission of a few pages with no formal methods section and no statistical analysis, its title makes clear it is explicitly being submitted as a work of advocacy, and two of the authors are consultants owning private practices selling programming methodology solutions to businesses.

Given they don't have a real methods section, I guess we'll never know, but the vague description of how they did seems to imply they split the class into people who completed assignments alone and people who completed them in groups of two. This does not seem to meet any definition of "pair programming" I would consider familiar to me. It sounds like a self-organizing team of two. How they split up work is not explained, but there is nothing here to indicate it was two people working at the same time with one typing and one watching for every line of code, just that two people were responsible for the same assignment as one person in the control group.

[rileymat2]

I agree with all your points.

And you can see with further googling, the results of better sources are all over the place. I did not cherry pick that one, it was just a sort of lazy google, look for a top result that was not clearly a blog.

I am just kind of frustrated at the seemingly poor science in the industry. But as I posted elsewhere, the "jelling" process rung true. Which complicates all kinds of one shot experiments.

[kosolam]

Students can’t be compared to industry workers. In my 20+ years of professional career in a multitude of companies of various sizes and domains, I have never seen pair programming implemented as a regular working method. Nothing that even gets close to this.

[JackMorgan]

A method can be effective and practical even if you've never seen it used.

My anecdata: I have worked at four different companies over fifteen years that all had pairing as a regular practice. Those teams had fewer defects, higher "social trust", zero silo areas, no cowboys, and rapidly trained Jr engineers into Sr engineers. They were much more aggressive at paying down technical debt.

I would estimate that pairing at least half of every day can produce Sr engineers 3x faster than just giving a new hire tickets and doing code review on a PR.

Also on a team with strong pairing culture, people often feel safe to "go home" in ways that I don't see in regular teams. Knowing that anyone on the team can handle any ticket you can feels quite liberating.

Obviously most engineers hate it though. It's less comfortable. Everyone I've seen who gets good at pairing comments that they are working a lot harder and getting a lot more done than solo. This is hard if you like to spend most of the day puttering around.

It's also not as great for deep thinking, so in teams with regular pairing culture it's a good idea to have forced solo time without assigned work just to make sure everyone gets that time to read, think, and process.

Of the four teams, one of them definitely was slower pairing, because they actually used mob pairing with 6 people on a zoom call and only the Sr guy typed. That was extremely ineffective but they didn't want to change because the other 5 loved just playing video games all day on a call. That team also was in meetings 6 hours a day, so they only paired like 90 minutes most days. That team had a lot of issues.

In my experience if you build a healthy pairing culture, it's the most effective way to build a highly trained stable team.

[rileymat2]

I agree, students and industry workers are not directly comparable. But one of the issues that I would wager is somewhat comparable is the human factors which, in the study above showed large inefficiencies in the first assignments before the "jelling" of the pair.

This makes most one shot studies problematic, it also makes starting to pair problematic if you are experimenting.

I have never worked in a full time pairing place, it was experimental, here there, sometimes. But the initial inefficiencies rung true to me, along with this jelling.

But, I have visited a place that did implement full time all the time pairing. (https://menloinnovations.com/our-way/our-process)

With all the money spent on software development, I am a bit surprised there are not numerous double blind experiments and studies where two different consultancies are assigned the exact same very complex project with staffed professionals using different processes. It would be extremely costly, but could pay the industry back many-fold.

[JackMorgan]

You hit on a key concept that we have no way to even measure productivity. We have no units of measure. What is a feature, they are rarely even comparable in any meaningful way. It's possible to have two projects that start the same but rapidly drift apart.

Not only that but different tools have different depreciation rates. I'd much rather try to restart an abandoned Java or C# project vs an abandoned PHP project, even though the PHP project might have been faster to add features at the start.

Because we have no measurements, we have no science.

[rileymat2]

You can make user metrics/surveys/delivery dates the ultimate adjudicator, in a blind way if you have created complete products. They will diverge significantly!

[kosolam]

In a pair programming setup what the pair does when collaboration isn’t needed but just pure coding? Do they separate and code in parallel or how does it go?