From last thread:

re: #217 Khal Wimpo (the extinguisher of tiki torches)

Well, having seen it in action, it is useful when attempting to crack really complex problem sets. It helps to have another person sitting at your shoulder - to bounce ideas off of, to check what you write in real time, to remind you of where you were going when you lose your way …

It’s actually more expensive in the short term, and managers hate it - but it turns out cleaner code. It’s like any other kind of complex writing - the more you can hammer on it to get it write the first time, the less time you have to spend later on clean-up.

[Embedded content]

The equipment cost is a fraction of a fraction of the employee cost.

My experience is similar. Here’s what I wrote up before seeing Khal Wimpo’s response.

I always felt that pair programming can be useful in a very specific and limited set of circumstances.

For example when a specific problem needs to be addressed for one of a limited number of issues.
- Such as when a subject matter expert (SME) is needed for a specific programming question.
- Or if the requirements are not well understood or documented.
- Or if there is little consensus on how a problem should be addressed. (Note this is more a ‘political’ and ‘leadership’ problem.)

But as a more general approach, I find it inefficient and a general waste of time and resources.