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.
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.
The Agile Toolkit Podcast did an interview with Arlo Belshee Tue, 9 August 2005
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.
A Study About Pair Programming in Practice
During a course at Lund University the students answered two surveys about pair programming. The first before the course. The second after.
The students were a bit more negative to pair programming after the course.
Practical recommendations about how to assign partners and tasks. What role should a team coach have in a pair programming team. How often you should change partners.
Most important personality types are not technical skills but social skills and worst personality types are dominant and ineffective.
Weaker developers liked pair programming more than the strongest.
- Authors: Mia Nyström, Johan Rix, Karin Wanhainen at Lund University
- Original title: En studie om parprogrammering i praktiken
- PDF: NystromWanhainenRix.pdf
Don’t miss the next ALT.NET unconference! Visit the site to sign up.
If you are not convinced see the photos from last event.
Coding QA Podcast – Episode 30 Pair Testing
- Pair testing makes you more open to think about the customer and corner cases
- You increase creativity by helping each other to see new solutions
- If you are having a bad day there will be someone helping you out
- You’ll be more effective pair programming
- Important to create an uniform workstation so you can pair on every workstation
- The rule: You aren’t forced to seek out pair programming but if someone asks, you to, you are required to join
Pair Programming Timer
A simple, egg clock like, timer that can be used to help you keep track of when to change driver.
Project page and Project blog
focus booster is a simple and elegant application designed to help you eliminate the anxiety of time and enhance your focus and concentration.
Can be used as a pair programming timer. Visit the Project page.
Remote pair programming
Don’t miss the Alt.NET ”unconference” this Saturday!
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
- And a number of other documents
Download all documentation from the Socio project (16 MB)
Development for this project is continued; see the Socio web site and the Sharp Wired web site for more information.
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:
I worked in the distributed systems team. See chapter 4 in the report for more information.
SEAGRID was a 50 person student project for the fourth semester at the IT University of Göteborg. We built a distributed system for an automated harbor with toys controlled by software.
After many hours ECos connected just fine through the stupid network sockets.