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.
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
Two pairs of eyes are better than one.
Designing and Programming is primarily a thinking activity. Contrary to O’Reilly’s "The Essentials of Copying and Pasting from Stackoverflow", real programming engages the brain, and no software (compiler IntelliJ whatever) can check your thinking.
Two is a better bus number than one.
If two (or more) developers know my (speaking as a manager, company owner) code base well, I am better off. The alternative is a single super developer on staff who can blackmail me with threats to leave and sink my start-up/team within the company.
Put differently, fire anyone who evolves into a super-duper expert on your code base.
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—
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.