A Dissenting Reply to
Stop Forcing Programmers to Concentrate

Text from original article

James Grenning's response

Programming, on the other hand, is a creative process. We often get stuck in a rut and need to clear our minds. When we return later we may gain a fresh insight or we may spot something from the earlier session that we now regret.

This is true, and not related to pair programming at all. I've noticed that when I get stuck, the other person has a different perspective and together we avoid getting stuck. I've had an important phone call in the middle of a pairing session, and when I return we are both back on the same thought process as before the interruption. If I was on my own the context would have been lost and it would have cost me quite a bit of time to get back into flow.

Last week's speaker obviously had no notion of program quality.

That's harsh. Maybe true, or maybe you did not understand them or your preconceived bias kept the meaning from getting to you.

There is one situation, of course, in which the programmer will feel lost returning to something from last week or even from yesterday: if the partially-done program is an undocumented mess!

That is not my experience with teams the encourage pairing and test driven development. TDD also helps keep track of exactly where the code is.

This is a special case of the task-switching prohibition discussed above. If I don't feel up to pounding away at a puzzling task, having a partner depending on me to persist until it's done just increases the pressure. With pair programming it's extra hard to switch to something else, and the pairs typically push through to the end. The programs they produce often show it.

Here you go with preconceived notions again.

When team collaboration does not discover a good solution to a problem, someone may have to go off and do some deep digging for a solution. in XP we call this a spike. In a team that pair programs after the spike is done, they apply what is learned to the production code. Production code is done in pairs. Knowledge gained during the spike is learned by the partner and spread around the group during later paring sessions.

assert(!((!Parm.activation.isPropertyContained)
|| (Parm.activation.isPropertyContained
&& ! Parm.activation.isTransactionIDSame) ||
(Parm.activation.isPropertyContained
&& !Help.CheckImplementationsFit())));

Why do you offer this as a example of code produced by pair programming?

A pair has two brains that are used to keep code readable and correct (better chance of that happening with two people checking the readability).

Whether a programmer sticks to a single task or switches among multiple tasks is really irrelevant if the programmer's commitments have been agreed to and recorded in the master project plan.

Conrad, try an experiment. Program for two hours uninterrupted. See how much you get done. The get a loud alarm and have it go off randomly over that two hour period. When will you get more work done?

The project manager doesn't need to micro-manage how the programmer spends his or her time. The experienced programmer knows the urgency of each task and its relative difficulty. He or she will make sensible choices in order to meet the commitments.

One problem is that many 'project managers' micro manage. What does this have to do with Pair Programming? Nothing... In XP and Agile the project manager, if there is one, is not involved in scheduling pair programming sessions. Pairing is more organic. A person with a given feature responsibility will pair with someone either to get some help and special knowledge they have or to share their knowledge with the other, in addition to the real time problem solving and code review. Raising the skill and knowledge of the team. This helps to make a more flexible organization with out the bottlenecks of people with specialties that only work in a few areas. Agile teams strive to have "generalizing specialist, people that have deep knowledge in multiple areas, general knowledge in many areas and are happy and quick to learn.