Bouncing off the evils of multitasking, C. Keith Ray (who just started his own blog) has this to say about how pair programming can counter some workplace interruptions:
Two effects pair programming has on tasking… in my experience…
It keeps the people focused on a single task (less likely to be distracted by emails, web-surfing, phone calls, people walking by, red herrings, trying the wrong design, bugs).
When one member of a pair does switch out of task to deal with a question or whatever, the other member can not only continue with the task, but also help the first one get back into the task, making switching (for a short period of time, like 5 or 10 minutes) less painful.
Still… I’d rather work on one project at a time, with the help of pair programming.
Other people report that people joining a project get up to speed much faster when pair programming, to the extent that “drop-in” programming is possible. In theory, this might allow some people to stay focused on one project (maintaining its continuity), and other people to switch projects frequently — I don’t know if this idea has been tested yet.
Keith makes a good point. It’s not just the number of tasks that wreak havoc. Interruptions from calls, drop-ins, meetings, announcements, loud music, questions, pagers, beepers, the latest crisis — can have the same effect on concentration and the same context-switching overhead.
Knowledge workers need periods of uninterrupted time to do their work — thinking. If people can’t find peace and quite in the cube farm, they’ll find it by searching out a deserted conference room or an unused storage closet. And if they can’t find a conference room or storage closet, they’ll come in early, stay late, or work on company holidays, because it’s the only time they can really achieve flow.
