The Tuple logo

Tuple's Pair Programming Guide

The Case for Pair Programming

This article focuses on an argument based on the author’s extensive experience with development and pairing. If you’d like to read a summary of scientific studies conducted on pair programming, check out our Scientific Research Into Pairing article.

In three sentences

Teams tend to ship slower over time because they accumulate sub-par code that impedes their progress.

A pair of programmers tends to produce better code than someone working alone.

Teams that pair often will maintain a fast shipping speed longer.

In three paragraphs

A team that ships slowly almost always does so because it is fighting a sub-par codebase. It spends lots of time fixing bugs and regressions, and finds that changes ripple across the system in surprising ways, requiring deep exploration to make changes. You can write code that minimizes these problems, it’s just much harder.

Pair programming brings more intellectual firepower to bear on this challenge. With two sets of eyes, bugs are caught earlier. With two brains to storm, more creative solutions can be found. With someone always watching, fewer corners are cut (and fewer distractions are indulged in).

Investing in higher-quality code through pair programming leads to a better codebase, which allows future development to proceed faster.

In three long sections

What actually slows down development?

The best way to answer this is to look at what teams that ship slowly spend a lot of time doing:

How can pair programming help?

How should we get started?

Check out our guide on your first pairing session.