Before I started pairing I often felt that there was a gap between business and development -departments. Communication was mostly done via bug trackers or specifications. Issues were ofter dealt with via e-mail and misconceptions were common.
Since I started pairing I feel a greater (not perfect but better!) contact to the business and I think it’s because I’m used to take discussions. Both about coding details, but also and more important about usefulness of requirements. If we are stuck on an issue we walk over to business and solve the issue instead of making it an e-mail-reply-cc-all-thing.
If I’m working on an issue with a person I don’t know I start out by shaking hands and talking to the person about what he or she does in the company and how they interact with the tools. I tell them what resources we have for the issue and we discuss a possible solution together. Just common sense.
It feels like software development is a too social activity to be done alone! At least for me!
Listen to Deep Fried Bytes – Episode 35, Chariot Tech Cast – Episode 39 and Hanselminutes – Episode 171 for more info about pair programming and other goodness about the software craftsmanship!
I’ve read up on some pair programming research. Here is the different papers I’ve read. With a short description for each.
Strengthening the Case for Pair-Programming
They compare results from professional developers working with and without pair programming and teams at the university doing both pair programming and non pair programming. In all cases pair programming deliver better results.
Authors: Laurie Williams at North Carolina State University, Robert R. Kessler at University of Utah, Ward Cunningham at Cunningham & Cunningham, Inc & Ron Jeffries
Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience
The optimal time between switching partner is 90 minutes and inexperienced developers solve problems both faster and better that people with previous knowledge about the problem. Beginners luck or just that you are more open without a baggage of experience?
A new developer was totally integrated to the team within 3 weeks of work. When not pairing they noticed a huge impact on productive. In 18 months the longest time it took to find and fix a bug was 6 hours. They also found out that a team is most productive when they own, manage and assign all tasks themselves.
Adventures in Promiscuous Pairing: Seeking Beginner’s Mind
They verified the performance boost described in Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience, which means short times (~90 min) between changing pairing partner. They verified the results but it also broke the team.
The fifth semester (at the IT University) I was part of a six person team that analyzed an existing application written for Mac OS X (in Objective-C), with the ambitions to reuse as much as possible of the application, though changing requirements for it.
The first requirement added, was that the new application (Socio) should be available on other platforms than Mac OS X. This requirement was achieved by building the new code in C# / Mono and embedding both the Mono runtime and the Objective-C runtime in a C application.
The second requirement added was to make the current monolith application extendable. This requirement was solved by creating a Plug-in architecture where the whole application runs as different plug-ins for the complete functionality.
The first thing that was done was an analysis of the current application followed by the creation of a requirement specification and architecture for this application (no requirements or architecture documents were available). Then we added the two requirements and created a new architecture that was implemented.
The hardest part in this project was to understand, learn and make all different techniques work together.
My roles in this project were as architect and developer.
The following artifacts were produced during the project:
Article – An Evaluation of Porting and Reuse Activities
The forth semester’s project (at the IT University), SEAGRID, was aimed to create a simulation of an automatic container harbor. The project was a mid size project with about 50 team members. To organize the project all team members where split into nine different teams, all with its own responsibilities.
I had two roles in SEAGRID where the first was as a team leader for the project team responsible for the network connection between all different nodes in the system. My other role was as a developer on parts of the network code. There are much learnings from being in such a big project, of which the most obvious is to realize how much work information and knowledge synchronization between different teams requires. Another learning is that the overall architecture and requirements affect how effective the organization works. A clear architecture is crucial to split the work load between different teams as early as possible.
Reports and source code from SEAGRID is available below: