So, the cost of losing one or both of the programmers in the process must be considered too.
My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code.
This is a popular argument among pair programming enthusiasts, which suggests there may be some merit to it. How do we reconcile it with another popular argument, that many programmers will naturally pair up on an ad-hoc basis when they're working on something challenging and/or interesting?
I can't imagine not wanting a second opinion from time to time, and I've certainly missed having one sometimes when I've been working solo on something and there was no-one else to talk about it with. But personally, I also can't imagine being comfortable in a full-time pair programming culture with necessarily restricted schedules and limited solo time. Sometimes, I just want to do some research or think through some ideas or play with quick and dirty prototypes for a while, even if I might be very interested in discussing my results or initial conclusions with other interested developers afterwards.
I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :)
I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things.
Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros!
I've never learned so much about programming as during my first ~6 months working together with people and learning their wisdom and tricks.
You're right that the restricted schedules are a downside.
I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming. I'm just questioning whether making it a formal, quasi-full-time arrangement is necessarily better than the ad-hoc version I see happening all the time for similar reasons and with similar benefits.
Sure, people help each other in various ways in most places. But that's the solo programmer on a task asking someone else for help. Two people work on a something together, from start to finish, is a quite different thing
Perhaps true, but not really the point the authors were looking at.
Sadly, it's dismissed out of hand as a "people problem" and "irrelevant". It really deserves more attention.
First of all, if you're looking for programmers to maintain a VB6 app, you really should factor into the economics of that endeavor the fact that most people don't want to code in VB6.
Second, no matter how potentially beneficial the pair programming approach is, there is a question of psychology in play. There are people who are introverted enough that the constant company required for pair programming will wear them down and cause them to quit or change teams. Dismissing it as a "people issue" and misrepresenting it as being unable or unwilling to be a team player is an oversimplification.
If you're pairing, don't read your e-mail. Even if you're just in a solo work session, don't read your e-mail. It's incredibly disruptive and constant inbox checking will drop your productivity like a rock.
It's okay to pair with multiple workstations (or a single workstation set up for multi-user mode, that's the dream I guess). Looking away from the "main screen" to check docs (or VCS, or the build, etc.) is perfectly fine, just don't get drawn in so deep that you forget about your partner. And certainly don't use that as an excuse to check your e-mail or slack!
One strategy to apply is "show, don't tell". If you have a hard time explaining what you're going to try to do, just do it, the code will probably be clearer than your explanation alone. If it's not, use the conversation to drive the uncovering of assumptions, which can then be encoded in the source.
Remember that pairing isn't simply two people, one keyboard. There are defined roles: the driver and the navigator. The driver handles mechanics, the navigator observes and questions assumptions. Then switch roles. The driver should fearlessly try the experimental things. If the navigator wants to experiment, ask to drive.