Pair Programming

Rules and Procedures for COMP 150

Remember, you are being allowed to complete your programming assignments with a partner ONLY as long as you follow the principles of “pair programming” as described below.

Each partner should “drive” roughly 50% of the time the pair is working together, and at most 25% of an individual’s effort for an assignment should be spent working alone. Any work done by a solitary programmer must be reviewed by the pair together. The object is to work together, learning from each other, not to divide the work into two pieces with each partner working on a different piece.

Make sure that both names appear on all work submitted by the pair.

If your partner doesn’t show up to a scheduled programming session, you may complete the assignment yourself. You should clearly document what happened in the log.txt file you submit in your assignment archive.

How to Pair Program

This summary is derived from “All I Really Need to Know about Pair Programming I Learned in Kindergarten”, by Laurie A. Williams Robert R. Kessler. You are welcome to read the full paper.  It starts with lots of data supporting the use of pair programming, some of it with computer jargon you do not need to worry about as beginning programmers. It elaborates on many of the points more than this summary:

Share everything. All contributions, whether leading to great results or errors, are ours, not yours or mine.

Play fair. One person drives (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work and planning ahead. Even when one programmer is significantly more experienced than the other, it is important to take turns driving, lest the observer become disjoint, feel out of the loop or unimportant. The person not driving is not a passive observer, instead is always active and engaged, checking over the work and thinking ahead.

Don’t hit your partner. But make sure your partner stays focused and on-task.

Put things back where they belong. Put negative judgments in the trash. Be positive about you and your partner. For both, this is an opportunity to improve.

Clean up your mess. Watch over the shoulder and you are really likely to find a large number of your errors!

Don’t take things too seriously. If your partner picks out a bunch of errors as you type, be glad there are two of you. But do not always agree. Have healthy disagreement/debate. Finding the fine balance takes adjustment.

Say you’re sorry when you hurt somebody while moving furniture. Sit side-by-side and program, simultaneously viewing the computer screen and swap the keyboard and mouse back and forth. Slide the keyboard – don’t move the chairs.

Wash your hands of skepticism before you start. Being skeptical can be a self-fulfilling prophesy. Buying in and gelling as a team can lead to a whole that is greater than the sum of the parts.

Flush. If you work on some parts independently either discard them (flush) and start over together or have your partner very carefully review the work with you.

Warm cookies and cold milk are good for you. Periodically, taking a break is important for maintaining the stamina for another round of productive pair programming.

Be aware of the power of two brains. Experience show that, together, a pair will come up with more than twice as many possible solutions than the two would have working alone. They will then proceed to more quickly narrow in on the best solution and will implement it more quickly and with better quality.