Two Heads Are Often Better than One

Programming requires deep thought, and deep thought requires solitude. So goes the programmer stereotype.

This “lone wolf” approach to programming has been giving way to a more collaborative approach, which, I would argue, improves quality, productivity, and job satisfaction for programmers. This approach has developers working more closely with each other and also with non-developers — business and systems analysts, quality assurance professionals, and users.

What does this mean for developers? Being the expert technologist is no longer sufficient. You must become effective at working with others.

Collaboration is not about asking and answering questions or sitting in meetings. It’s about rolling up your sleeves with someone else to jointly attack work.

I’m a big fan of pair programming. You might call this “extreme collaboration.” As a developer, my skills grow when I pair. If I am weaker than my pairing partner in the domain or technology, I clearly learn from his or her experience. When I am stronger in some aspect, I learn more about what I know and don’t know by having to explain myself. Invariably, we both bring something to the table and learn from each other.

When pairing, we each bring our collective programming experiences — domain as well as technical — to the problem at hand and can bring unique insight and experience into writing software effectively and efficiently. Even in cases of extreme imbalance in domain or technical knowledge, the more experienced participant invariably learns something from the other — perhaps a new keyboard shortcut, or exposure to a new tool or library. For the less-experienced member of the pair, this is a great way to get up to speed.

Pair programming is popular with, though not exclusive to, proponents of agile software development. Some who object to pairing suggest “Why should I pay two programmers to do the work of one?” My response is that, indeed, you should not. I argue that pairing increases quality, understanding of the domain and technology, techniques (like IDE tricks), and mitigates the impact of lottery risk (one of your expert developers wins the lottery and quits the next day).

What is the long-term value of learning a new keyboard shortcut? How do we measure the overall quality improvement to the product resulting from pairing? How do we measure the impact of your partner not letting you pursue a dead-end approach to solving a difficult problem? One study cites an increase of 40% in effectiveness and speed (J T Nosek, “The Case for Collaborative Programming,” Communications of the ACM, March 1998). What is the value of mitigating your “lottery risk?” Most of these gains are difficult to measure.

Who should pair with whom? If you’re new to the team, it’s important to find a team member who is knowledgeable. Just as important find someone who has good interpersonal and coaching skills. If you don’t have much domain experience, pair with a team member who is an expert in the domain.

If you are not convinced, experiment: collaborate with your colleagues. Pair on an interesting, gnarly problem. See how it feels. Try it a few times.

By Adrian Wible