Pair Programming Grading Policy

The intent of this policy is to provide some incentive for students to give pair programming a serious try. Research suggests that both experienced and inexperienced programmers tend to

• be resistant initially to pair-programming, and
• find it very beneficial and enjoyable once they get over their initial resistance.

Why Pair Programming?

The benefits of pair programming include:

1. Its more fun.
2. You learn how to clearly explain ideas to your partner. Communication is a crucial skill in software engineering (as in almost all walks of life).
3. Being able to explain something helps you understand it better.
4. You can learn from your partner.
5. You waste less time debugging. By having two pairs of eyes stare at the code as you write it, you'll find many bugs straight away, rather than wasting many hours debugging.

Pair Progamming Guidelines

1. You and your partner should work together, alternating driving and navigating, spending roughly equal amounts of time in each role, and switching regularly, no less than every half-hour.
2. Spend at most 25% of your total programming effort on the assignment working alone. When the pair gets back together after either partner has worked on the code alone, review, line by line, the work done alone before doing any new work. Strictly speaking, pair programming when done as part of the "Extreme Programming" software development process, requires that any code written by a solo progammer must be discarded and rewritten.
3. You can spend at most 15 minutes alone finishing up a program after your last meeting with your partner.

BOTH partners in a pair should submit the program. This is required to avoid the "I thought my partner was going to submit it" problem. When you turn in each programming project, include a comment:

/**
  * Assignment #1
  * Author: Cormac Flanagan
  * Partner: ...
  * Time programming together: ...
  * Additional individual effort: ... (should be a small fraction of the pair time)
**/

What to do with Pair Programming problems?

The following are examples of failed attempts at pair programming that require documentation. The list is by no means complete.

• You and your partner complete the program together but substantially deviate from one of the 5 guidelines above (e.g. too much time working alone).
• You begin working with your partner but then you cannot finish it together and you finish it on your own.
• You and your partner never manage to get together.
• You get together with your partner but it just isn't working for some reason (e.g. they always want to drive, they never want to drive, they clearly aren't studying and don't come prepared to your planned sessions).

In such situations, try to resolve the situation through communication: talk constructively with your partner about how to address the issue; or talk with your TA or instructor. Communication and teamwork is an extremely valuable skill in software engineering, so this is an opportunity to improve these skills.

What do I do if my partner doesn't show up to our scheduled meeting for working on a programming project?

You may work on your own. If you complete it, there are several options that depend on what happend with your partner.

Case 1: Your partner has not yet done the assignment.

1. You can submit your own solution and your partner can work alone, completing their own solution (see Pair Split below).
2. You can scrap your solution and work with your partner on a pair solution. In this case your partner must drive and you must review until you have a program that is at least as good as the one you scrapped.
3. Your partner can work alone until they have a solution. At this point it becomes Case 2 below.

Case 2: Your partner also completed the assignment alone.

1. You can each submit your own solution (see Pair Split below).
2. You can scrap both solutions and redo a combined solution. This is referred to as "flushing" in the Pair Programming paper handed out the first day. This will almost certainly result in a much better program. Programs are almost always better the second time. This is true in commerical software developement as well as in educational settings. You will also learn from the experience.
3. You can combine your solutions into a single solution. In this case the work incorporated into the final solution must be carefully reviewed by the partner that did not write it.

If you work alone but do not complete the assignment, you may meet later with your partner to complete the assignment with the following provisions. Either the total amount of time you spent working alone must be no more than about 25 percent of your total effort on the projects, OR you must scrap the code you wrote on your own and rewrite it with your partner.

A final option is not really an option but I feel compelled to mention it. You can lie by being dishonest about what you put in the log. Of course if this is discovered you will be disciplined appropriately.

Pair Split

If you spent any time working on a program with your partner but then do not finish it together (recall that you can spend at most 15 minutes finishing up alone after your last meeting with your partner and still say you used pair programming), finish it on your own and include a header comment such as:

/**
 * Assignment #1.
 * Author: Charlie McDowell
 *        I spent 3 hours with my previous partner Jane Programmer
 *        working on this assignment. I spent another hour finishing it
 *        up on my own.
 */

In no case should you list your partner as a co-author if they did not finish the program with you.