Every programmer knows that interruptions are frustrating because it lowers their productivity. But now, there’s empirical evidence showing this:
Game Developer Magazine analyzed 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio, and surveyed 414 programmers, and discovered that a programmer needs up to 15 minutes to start editing code again following an interruption.
Unfortunately, managers don’t always realize the way these interruptions affect developers. In a manager’s mind, there’s one less thing on their plate when they communicate it to a developer. A more effective form of communication would be to write down the thought and talk to the developer in a scheduled meeting. If there were some way to avoid interruptions, that would be ideal.
But some interruptions are unavoidable. When you do feel like you’re being interrupted too frequently, pair programming can be a way to offset the damage caused by these interruptions. Here’s why:
If you’re soloing and someone interrupts you, 100% of your context is lost. You have to shift gears to deal with the interruption alone. But if you’re working as a pair and someone interrupts you, you can choose to split the pair and only let one of the people get interrupted. Meanwhile, the other person continues working on what they’re working on with 100% of the context. When the pair reforms, the one that stuck will fill in the context for the one that left.
If both pairs choose to be interrupted, pair programming helps with that situation, too. Pairs are more resilient to the context switching cost. As soon as the pair gets back to work, one of them will ask, “What were we working on?” and they’ll each remember a piece of the context so they can get back to their work faster. There are social pressures that prevent one of them from reading email or checking Facebook before they continue with their work. When you solo, those social pressures aren’t there.
Another reason pair programming helps with interruptions is that people are less likely to interrupt an active collaboration. This is more likely to be true in an environment where only some people pair. All things being equal, do you interrupt? The people in the middle of a conversation or the person who’s sitting alone by their desk?
Interruptions kill productivity but they’re also a fact of life. Pair programming should be considered as a tool that can be used to reduce the negative affects of these interruptions.