I’ve seen pairing work in areas other than programming. At Lockheed, we did “pair analysis” and I had my architecture team in Motorola try out “pair architecture”. The reasons are largely similar to that of pair programming, but there were some unique benefits as well.

First off, I have to admit that neither of these were strict pairing in the sense of working together on a work product at the same time. And in both cases, the team was made up of people with similar experience levels, but with different knowledge areas.

At Lockheed, my manager did this with a group of us who were responsible for designing the various attitude control and sensor processing algorithms for the Iridium satellites. This included characterizing and modeling the various hardware components.

One of the key drivers for doing this was the fact that Iridium, unlike most satellite designs, had no dedicated safemode hardware or operations mode. We had to make do with the different components that were there for the main mission. This meant we had to reconfigure the hardware and control modes in a large number of combinations based on potential hardware failures at different points of the mission.

In the face of this complexity, my manager paired up all of us so there were at least two people responsible for being knowledgable about each piece of hardware and about each control algorithm. The pair was responsible for understanding and signing off on hardware test data from the vendors and control algorithm designs.

The brilliance of this approach was that it directly fostered the understanding needed to be able to design new combinations of hardware and algorithms to cover the different failure scenarios. It created a connected communication network that minimized the number of hops between expertise domains (software is a communications business, after all).

In Motorola, my motivation for doing this with my architecture group was a little different. Premature parallelism can be a rampant problem in large system design. My goal was to force cross-communication, but limit it so it didn’t become a productivity bottleneck. Also, I have to admit, some of it had to do with the fact that I didn’t trust individual people to be the sole authority and final say in an area. I was more comfortable if someone else agreed on the approach as well and had no desire for myself to be the bottleneck through which all decisions passed.

At times, architecture reviews would be all over the map because people weren’t in synch. You kind of expect some of that at the very beginning of a project, but it isn’t productive to have everyone involved in all discussions for the whole project. I wanted a system that made sure we kept in synch on the big issues yet allowed productive individual progress.

I figured the best way to get people in synch was to start with pair-wise responsibilities. We defined a candidate architecture together well enough to have major components and interfaces identified, then assigned a pair to each component. The goal was to get everybody thinking larger than they normally would and to make sure that the team dealt on a whole with major issues, not minor ones. Another goal was to foster the communication network benefits I saw previously.

The pair worked out issues or differences of opinions as best they could. If they came to agreement, great! I trust that two smart people working together can figure out an approach without being second-guessed by everybody else. If they could not agree, the process of discussing between themselves at least crystalized the different alternatives available and the relative benefits between them. Instead of a meeting where everybody got bogged down trying to solve every problem, we could have a meeting focused on contentious issues and how they might affect all the whole system.

I have to say the outcome wasn’t as good as what I had at Lockheed. A small part is that there is a cultural difference between the two companies. Another part of it was that I was with the Lockheed group longer. We worked as a team longer and had more time to use the process. Probably the biggest contributor was that the Motorola group had a long history of individual ownership of areas by the architects. I’m not knocking it, there are benefits to that approach, but it meant that the culture couldn’t be expected to change entirely in the course of one project. I’d definitely do it again and in general think the problem of finding balance between premature parallelization and group paralysis is one of the key problems in building systems.