Tony's tech terms: Pair programming

We work in pairs a lot. On face value, it would seem that we’d get about half as much done. Multiple studies have found this to be a false assumption. For example:

In a 1999 controlled experiment in a classroom setting, Dr. Laurie Williams found pair programming took a team about 15 percent more developer hours than working as individuals. However, she found defects to be 15 percent lower, design quality higher, and the project completed in 45 percent less calendar time.

—Practical Pair Programming by Jason Garber, page 6

We see a lot of benefits from pair programming. It prevents us from working in isolation. Having someone else present to check our thinking reduces the number of errors and results in better, more stable code that is easier to maintain. We write code that is intended to be read and understood by other developers—sometimes years later. Working with another person improves our code readability.

It also spreads context on the team so that it’s easier to support our applications when someone is on vacation or sick. And it helps us maintain relationships with each other since we mostly work remotely. Everyone on the team rotates through a pairing schedule. We learn from each other as we each bring our own tips, tricks, and experiences to share.