Most corporate developers are hermits, isolated by the grey walls of cubicles. Certainly there are meetings, committees, lunches, and corporate events, but strip that away and focus on the core of our work and you see that each day, we arrive at work and setup shop in our small piece of corporate real-estate. This is the reality for the majority of developers and it's no small wonder considering that we have been conditioned to work as lone wolves from the first grade on. (Changing Education Paradigms)
Let's look at our typical day. If we are focused, we jump into the day's tasks and if not, we futz about with social sites, e-mail, browsing, etc... until we can no longer delay the inevitable. During the day, we face many interruptions. These come as external interruptions such as phone calls, coworker visits, and e-mail notifications, as well as internal interruptions like lapse of concentration or moving off task due to a tangential idea. Once off task we may have to motivate ourselves to get back on task and at the very least, reload all of the context that was lost.
Speaking of tangents, we'll take one now to ponder the movie Matrix. Consider the plight of our protagonist Neo in the first 30 minutes of the movie. There he was, a questionably productive corporate developer for Metacortex with his own cube and a future of working toward the corner office. However, Neo sensed there was a problem with this reality which continued to manifest itself in more bizarre ways leading him to make increasingly uncomfortable decisions to the point where literally stepped out on a ledge.
This is not unlike many corporate developers today who have sensed that the reality traditional development practices may not be the only way to create software. Some have asked and acted on the uncomfortable questions. What would happen if I didn't write code alone every day? What if we all knocked down the cube walls so we knew what each other was doing? Would it increase communication? Create accountability? Many of these questions have been answered for us and backed with empirical data.
Laurie Williams outlines the following three tests in her book "Pair Programming Illuminated".
Finally, Williams summarizes the studies by breaking down the comparison factors to efficiency, the percentage of time spent developing new code, and overall productivity, the average hourly output of defect free code. Her findings? In the end, pairs were twice as efficient, spending 34% of their time writing new code versus the 17% rating of solo programmers. Overall productivity increased from 4.3 to 7.4 lines-of-code/per person hour. So while it might seem that having two developers work on the same code at the same time would cut productivity in half, the inverse is actually the reality.
What does all this mean? Like Neo, it will come down to a point where we have to make a personal choice about how we perceive pair programming regardless of whether our corporate structure embraces it or not. Will we step out of our comfort zone, give up our personal space, be willing to risk scrutiny of our work by others and ultimately take the red pill? Or will we head back into our cubes, blue pill in hand, attempting through sheer force of will to prove to the Neo's of this world, and ourselves, that solo programming is a workable reality.
