I was a long-time skeptic of pair programming. More than anything I think I was resistant because the prospect of sharing a keyboard with another developer sounded unappealing, even if it worked. Like most developers, I like to tinker with code… try one thing… Google for other people’s solutions to the same problem… tinker some more. How would this work in a pairing situation?
People with more agile software development experience than I had would say two things: 1) it works, and 2) you have to try it to believe it. But for years, I only dabbled in it, never getting past the discomfort of it–sort of like deciding to take up running. You put the shoes on and huff out a mile or two only to feel terrible and put up the shoes for another six months until the guilt wells up again. You don’t make the breakthrough to enjoying it and realizing the benefits until you get better at it and get past the initial discomfort.
It was only after trying it for a sustained period of time at VersionOne that I came to appreciate that both things I was always told. It worked and I had to try it to believe it. The increased focus and benefit of talking through the minor design decisions that get made as we write code more than made up for any productivity loss of having each of us work on different problems at the same time. At VersionOne, we even found, during early feature design stages, we would have three of us, Visual Studio, and a whiteboard. We would design and code as a team. The consensus was that we tended to craft our best solutions and write our best code during those sessions.
Now I find myself in a position of advocating pair programming at Agentek. As you might guess, I’m saying things like “It works, but you’ll have to try it out for yourself to believe it.”