8.3.0.5

Lecture 7: Pair Programming

You may have seen pair programming since freshman year. You may not have taken it seriously. But here is our rationale for this course, and it should be the rationale for any company that values its code base.

What and How

Two people take turns to design and interpret interfaces, design functions, add tests for bugs, debug using the test suite, and deploy the software on Linux.

The ideal physical setup is a one keyboard/one monitor, i.e., these days one laptop. One of you is designated pilot, the other is co-pilot. Switch roles every so often, using an agreed-upon protocol: completed tasks, fixed time interval, etc.

The pilot writes down thoughts as designs, interfaces, protocols, code. The co-pilot observes and continuously questions the pilot’s actions. Here are some sample questions:
  • do we understand what knowledge a component encapsulates?

  • what data definitions are used for that?

  • what are the key pieces of functionality?

  • how should those be exposed, if at all?

  • do we have good signatures? do we have well-articulated purpose statements?

  • are we following the design recipe in the small (for functions), in “coding life?”

As you execute, neither of you can slack off. You must execute your roles properly all the time. If you notice slack, switch. If both slack, take a break.

In a team setting, rotate pairs so that everyone gets to know everyone as a partner. And everyone gets to know the code base reasonably well.

Why

Strengths and Weaknesses

You may think you can do it alone. What if you get sick?

You may think your partner can do it all. If so, you’re a lazy bum and when your boss finds out he must fire you—to act socially responsible as a boss.

You may think you’re wasting time when two do what one could do. But one cannot do what two do: continuously critique each other.

In general, people have unequal skills. The key is to use each others strengths’, learn from each other, and soften each others’ weaknesses.

Evidence

Laurie Williams and Bob Kessler some 20 years ago published a comprehensive book after studying the use of pair programming in a variety of settings, but mostly industry. They came to the conclusion that pair programming saves companies money in the long run.

Besides the advantages already mentioned, pair programming creates ties between people and, if well managed, these ties are positive, self-reinforcing ones. These ties, in turn, binds people to the company, avoiding costs with on-boarding new people.

If you ever need arguments for pair programming, I recommend you read the book.