Pair-programming: a peer to peer information system
I’ve worked on projects where we did pair programming most of the time, and I’ve been on projects where we only pair on specific issues, and as soon as it looks like we can get back to our “own” work, we do.
On a project where I’m not pairing, I miss the way information flows about the team. My favorite as a developer are the practices that other developers use as they work; The various programs that they prefer, or other tools that they discover. Most of the IDE shortcuts that I know, I learned because I paired with someone who used it, and I asked them to teach it to me. I find that there is constant learning process as a developer where someone will have some tidbit of knowledge that they share with you. Best practices are easily shared, from CSS tips to database practices.
If you do pair programming in a team of collaborative and knowledgeable people, it’s like being in university every day, but it’s all projects and no exams. Sometimes, you are the teacher, and other times you are the student. Either way, the rate of personal learning and growth is greater than if you worked alone. It’s a fun experience.
There is another important flow of information that is missed without pairing. When software grows to a certain size, the complexity of the code base (and the domain) becomes an increasingly difficult issue to manage with teams that don’t pair. Different design patterns are commonplace and entire areas of the system are built that some developers never know exist, let alone are able to immediately work on. Inevitably, a “silo” effect happens where people tend to work on what they have worked on before.
When a team successfully does pair programming, every developer will eventually be exposed to every area of the system. Every pattern will be scrutinized, and it’s strength and weaknesses better understood. The business value of the features being worked on will be understood by everyone.
People that have information that is not shared with the rest of the team become centralized stores of information. How often had we needed to talk to one person to complete our work, but couldn’t get any of their time? I’ve even seen meetings and other sessions around one or a few people trying to disseminate information to everyone at once, through handouts and power point slides. Such attempts are an ineffective way of sharing information.
August 2nd, 2008 at 5:44 pm
One could argue that broadcasting information is more effective because you only say things once. When you disseminate information pair by pair, the information is often repeated to every developer.
Of course I agree with your point. The one-on-one conversations are always more productive and will happen only on a need-to-know basis, which ensures the information is useful.
August 2nd, 2008 at 8:12 pm
Well, in theory broadcasting information is a good thing, but I don’t think the benefits apply to developing software. An analogy is that I can explain the step by step process of assembling a bicycle. Most people would not be able to assemble a bike after hearing me tell them how to do it, let alone appreciate the often subtle best practices involves. However, doing it with me right next to them would probably result in a well assembled bike and with them very capable of assembling another.