Pair Programming and the Source Code Communication Network
Posted on Wed, Jul 25, 2012
by Garrick West
Pair programming background and reconsideration
Proponents frequently assert that pair programming is the power of two developers working with the heightened creativity that comes from good collaboration. It gained some notoriety around 1999 as one of the 12 required practices of Extreme Programming (XP). At the core, pair programming is a way of incorporating continuous code review. One developer is working tactically (editing source code, running tests; “driving”) and one is working strategically (considering design and next steps, managing subtask lists; “navigating”). Pair programming is (unfortunately) one of the most controversial technical practices under the umbrella of Agile software development due to the perception that its collaborative nature is “waste”.
After reflecting on nearly 8 years of doing pair programming on all production code, I gained an appreciation for thinking about communicating software design with other developers being like network topology. I recognized that compared to production quality pairing work, soloed prototypes or research projects required much more communication overhead and incurred more misunderstanding. If you take issue with the past studies, if you dismiss it for “simple”, “mundane” development tasks, imagine 6 developers building just one critical part of your application and then reconsider pair programming as improvement to your source code communication network topology.
Developers and the source code communication network
As a developer, you learn that being able to build and maintain software in a team requires understanding and communicating an evolving design and implementation for the life of the code. Since a picture is worth 1,000 words (before factoring inflation and local currency adjustments), think of each line in the diagram below representing the message passing of not only code, but design and vision captured in each source control commit message from a given node:
Pair programming simplifies the source code communication network
As you can see from the diagram above, good pair programming significantly simplifies the communication about source code between developers. Notice, I said “good pair programming”: that means that both members of the pair are already communicating effectively and have a comparable level of understanding about what they’re working on. It may take time to build up the skills of all team members, but pairing helps this happen naturally over time.
The simplified network saves on communication faults
There’s also a subtle advantage to the simplified model as well. In the case of messages being sent (e.g. source, design, and vision) not one, but both members of the pair must misunderstand in order for there to be a “fault” or bad message.
Summary: Or “All models are flawed, some models are useful”
If you’ve dismissed pair programming in the past, reconsider the benefits in terms of the proposed communication model. Think about how your most critical source code has been managed and changed over time. Ask yourself or your developers: “What’s the most critical part of our source code, and could pair programming help make us better at delivering it?”
Recommended Reading:
All I really Need to Know about Pair Programming I learned In Kindergarten
Pair Programming Illuminated
References:
Network Topology
Communication Theory