“Bus factor” argument is a bad one. It assumes that without pair programming developers divide parts of the code between them and never touch each other code. How is that right?
“Technical debt” – there is a much better (and cheaper” way to achieve quality. It is code reviews. These achieves better results in terms of quality while not forcing people to sit in an uncomfortable position while looking over each other shoulder.
Knowledge transfer might work for some people, but not for all. Many people learn better when they have time to think, not when someone else provides them with ready answers.

As for “wasting money” – there is a lot of it in the software development industry. I have worked in it for long enough to know that.
BTW – the worst waste of money I have seen in my life was in a company where IT was run by former ThoughtWorks employees (ThoughtWorks is another consultancy with mandatory pair programming). It was the only place when the re-written a not that old application twice in two years, first in Java and then in Scala, for no apparent reasons. There was forced pair programming to the company (I guess they still felt like consultancy employees).

http://sceptical-meerkat.blogspot.co.uk/2016/12/pair-programming-whats-in-it-for-me.html

Hi,

This only may sound like a waste of money, but in reality even our developers–who paired with Pivotal, by the way (!)–are very excited about the efficiency of pair programming. I asked them why they like the Pivotal approach, and they mentioned a couple of reasons:

–lower technical debt (https://en.wikipedia.org/wiki/Technical_debt)
–better “bus factor” (https://en.wikipedia.org/wiki/Bus_factor)
–extremely fast knowledge transfer (up to 5x faster onboarding–due to having a person who is aware of all details/pitfalls/issues)

If PP wasn’t efficient that much, Pivotal wouldn’t have use it for their own internal projects. However, you’d better ask them or collaborate with them–I don’t think it’s a good idea to make assumptions and discuss the company without involvement with them. I also do not think that a manufacturer like Daimler/Mercedes would waste its money in vain. When the speed of delivery matters (and matters a lot), and PP can accelerate the process, why not?..

At the same time, Pivotal wrote “pair programming isn’t for everyone or every company.” So, sure, it depends. =)

This tweet explains it in short–better than thousands of words: https://twitter.com/benrady/status/817430925176958977 — There’s nothing more to add. =)

Hi,

This only may sound like a waste of money, but in reality even our developers–who paired with Pivotal, by the way (!)–are very excited about the efficiency of pair programming. I asked them why they like the Pivotal approach, and they mentioned a couple of reasons:

–lower technical debt (https://en.wikipedia.org/wiki/Technical_debt)
–better “bus factor” (https://en.wikipedia.org/wiki/Bus_factor)
–extremely fast knowledge transfer (up to 5x faster onboarding–due to having a person who is aware of all details/pitfalls/issues)

If PP wasn’t efficient that much, Pivotal wouldn’t have use it for their own internal projects. However, you’d better ask them or collaborate with them–I don’t think it’s a good idea to make assumptions and discuss the company without involvement with them. I also do not think that a manufacturer like Daimler/Mercedes would waste its money in vain. When the speed of delivery matters (and matters a lot), and PP can accelerate the process, why not?..

At the same time, Pivotal wrote “pair programming isn’t for everyone or every company.” So, sure, it depends. =)

This tweet explains it in short–better than thousands of words: https://twitter.com/benrady/status/817430925176958977 — There’s nothing more to add. =)