Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles.
My guess as to why we don't see more adoption is 1) most developers aren't that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned.
edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.
If it became a required part of daily work in my company, I don't think I'd be around for long.
For what characteristics of problem is pair programming more useful, when such problems arise? Is there a pattern to plan for?
My opnion is that people need time and practice to aborb. Everyone has there own way. If you are pairing everyday for no other reason then company policy, it sounds like the worse place in the world to work.
When I do pair, I only work for 3 or 4 hours that day total.
The best model would be four hours of pair programming and another four of paying those programmers to take a long lunch, a nap and a walk. Those 4 keyboard-hours would probably be as productive as 16 keyboard-hours of the same programmers working independently for a full day, if not more. And unlike full time pair programming it would be sustainable.
So we have to "play" the game of looking busy and appearing productive for appearances.
"Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes.
I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims.
As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize.
As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.
I've been programming at various levels of abstractions and different stacks for 20 years. I often have very good intuition on diagnosing and solving technical problems. It's very hard to verbalize this, especially to people without the same background, it's intuition built on hours and nights of pain and debugging/googling/prototyping and I often need to search and REPL/prototype things to know I'm going in the right direction.
So I waste time dragging the other person along my mental path, and when I go into a wrong direction the cost is also increased by having to explain what I'm doing + the other person usually being annoyed at being dragged along for something they barely understood and it ends up being for nothing.
But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.
While I agree with that, the cost-tradeoff is not worth those improvements (which are slight). Feel free to post to the studies that you find compelling.
No it doesn't, bugs happens since there is much acceptance for bugs, programmers develops just enough awareness of them to get the bug count to maximum acceptable levels. If you take two programmers who both learned to get there on their own and have them oversee each others work, you reduce the bugs temporarily, until they adjust their attentiveness and conscientiousness downwards to account for it and the bugs rise again until they are at barely acceptable levels.
You see temporary improvements like this happen everywhere. Researchers love it because it makes it trivial to publish papers, but these results usually doesn't scale, and even when they do scale the effect is significantly smaller than originally advertised.
Meanwhile, some of that research is pretty easy to deflate. From the first article, for example:
Students prefer the 15% overhead
That's right -- they used a survey of student experiences to draw conclusions about what works best for senior developers well into their careers. As the authors themselves put it: "We feel that this is a strong indicator of the satisfaction of pair programming."
I don't see how they can call this "strong" evidence of anything.
Teaming up for training is absolutely crucial at this time.
To give a more concrete example a pair programming session might avoid putting in foundational code that ends up being a bad design choice and slowing down the team by 1% forever. Maybe at a cost of millions. That 1% will never show up in any OKR or KPI that just basically measures superficial stuff about the status quo (bugs raised per quarter, features delivered on time etc.)
I mean it is like we forget we live in an age where still someone smart coding at their laptop can launch a million dollar business.
If you can figure out a smart “hot take” way of working, like maybe pair programming it is a big competitive advantage.
To the point you probably wont find a job for a company that works that way because they can more than make do with a small team.
If you have a team of experts, and you want to keep them all experts, it's much more economical to have two people learning the new code as it's being written. Theories about what might or might not be helpful have very little value until tried in the field.
Would anyone ever say you only need one copy of the code, because backups are inefficient?
You’re forgetting that it’s impossible for any one person to keep all the details of even a medium sized code base in their head.
I imagine the initial “planning” phase of implementing a change would benefit heavily from pair programming because it avoids the issue where you write a bunch of code to find out that it doesn’t work because of this one detail that you forgot.
For the learning (“knowledge transfer”) aspect, though, I think you’re right that it’s possible to reach a point where writing the actual code (not the design) as a pair is not worth it.
It may not be as efficient, but it can be more productive in the long-term if you're better insulated from staff turnover, for example. Making engineers more replacable could also contribute towards lower wages (more able to hire beginners and make them competent, reduce leverage of existing staff).
While you can type a lot more by having two people type in parallel, some programming is much heavier on the problem solving aspect of things and those types of problems are sometimes completed more rapidly with two people working together than with two people working separately.
Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert.
Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.)
On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently.
Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.