Pair Programming

Revised 2016 Sep 22.¹

(These notes are primarily for INFO-I210, but may also be used by some other classes.)

Pair programming is simply this: two programmers work simultaneously, one as driver and the other as navigator. The driver operates the computer (or records the design or test plan, etc.), while the navigator observes and comments. The navigator should ask questions and make constructive suggestions. After a designated time (perhaps 20 or 30 minutes, depending on your pace), the two switch roles, and continue switching periodically until the project is done.

Watch this to learn about pair programming:

Special Considerations for Our Class

There are three circumstances that …:

1. There may be an odd number of students in the class, or in a section. Perfect pairing requires an even number. How do we “pair program” with odd numbers?

2. The instructor requires a pair programming log, mainly to verify the students (especially online) are really pair programming, which is a much tighter form of coordination than just “working together.”

3. The video describes pair programming face to face, but how do we do it in an online situation?

1. Odd Number of Programmers

What if there are an odd number of programmers? You cannot assign everyone to a pair in that case.

There are two solutions:

1. Allow one team of 3 students.
2. Have one person do something else, such as code review.

We will use the first solution, allowing in each section one team (only one!) of 3 students. For such teams, there will be, at any time, one driver and two navigators. When it’s time to switch roles, rotate uniformly, like this:

2. Logging Requirement

To ensure that “pair programming” really is pair programming and not some looser form of working together, I will require pair programming teams in INFO-I210 to turn in logs of their working sessions. (If you are in another course, see the assignment instructions to determine if logging is required.) The logs will show who was driving, who was navigating, times of role switch, what was accomplished before each switch, etc.

These are the logging requirements:

Keep a log of your working sessions. By “session” I mean a period of time in which one person is the driver and the other is the navigator. In the log, write the start and end (date and) times of each session, who is the driver, who is the navigator, and what was accomplished. (In the exceptional case of a “pair” of three students, sessions will have one driver and two navigators.) Also describe any problems you encountered in developing the program, and explain how you solved them or attempted to solve them.

Additional requirement, for Lab 6 and later, added 10/19/2015:

If you are pair programming online, your log should also identify the tools and technology you use for this (e.g., Google+, Big Blue Button, pastebins), and tell me about how well this technology works for you. You don’t need to report this separately for each session, unless it changes; just once at the end of the log is enough.

Example

Problem Notes:

1. Having trouble locating the year within the string argument. Solved by indexing with negative index.
2. Having trouble joining title + first + … + rest: string + list error. Solved by bracketing the non-list items: [title, first, …] + rest.

Tools and technology: For online pair programming we used Google+ Hangout for voice and screenshare, and pastebin.com to exchange code when we switched roles and when we finished. No problems.

3. Online Pair Programming

Pair programming got started, and may be easiest to practice, with two people in the same room, literally side by side and looking at the same computer. It is also possible to do pair programming on line—two people in different rooms, not side by side, each with a different computer. But how does that work?

What we need to do, more precisely, is three things:

1. Communicate efficiently (i.e., by voice).
2. Both people see what the driver is doing on the computer.
3. Switch roles, so that the new driver takes over editing the same code that the old driver left. (And even if you are working face to face, you should probably exchange code with your partner, so that you both have a copy afterwards.)

What I would probably do, if I were pair programming with one of you in an online class, is use Google+ Hangouts. (Use Canvas Inbox to share your Google+ Profile URL with your lab partner.) The driver can share the screen to show to the navigator—you have all done this in the hangout test. You can talk to each other. There is even a “remote help” tool, which allows one person to control another’s computer, and we could try that when it’s time to switch between driver and navigator roles. If that didn’t work well, we could use a paste bin to share code.

But there are also many alternatives, so use what you like.

1. Voice communication: telephone, Skype, Adobe Connect.

2. Screen share: Zoom, Adobe Connect, other resources (see below).

3. Switch roles:
   1. Other tools for remote control of a computer (see Tools and Resources, below).
   2. Instead of giving remote control, you could send the code to your partner, using a paste bin, email, Canvas Inbox, IU Box account, etc. (see below).

Tools and Resources for Online Pair Programming

Note: I haven’t tested all of these, or even most of them.

Video-Conferencing and Screen Sharing

• Zoom
• Google+ Hangouts
• Codeshare.io
• TeamViewer. Some students have found this very useful. It is “free for private use” / “free for all non-commercial users”, but not open source. It is available for Linux, Windows, Mac, and 4 kinds of mobile operating system. I have not tried it myself.
• Adobe Connect Meeting
  • See Web Conferencing
  • Adobe Connect Meeting does not adequately support Linux: screen share does not work, web cam and microphone require work-arounds.
• Skype

Sharing Source Code

• Pastebin.com or similar services (you can Google for the competition). You can paste your code and then tell other people where to find it. Your pastes can be public or unlisted (unlisted = URL is known only to you and those with whom you share it), with or without an account, and they can be set to expire. For simple programs like we’re doing in I210 (at least so far), I think it’s a good option.
• Attach source files in email, or Canvas Inbox, messages to your partner, or upload into your Canvas group space.
  • Use an email client or web client (web browser) on the machine (e.g., merlin) where the file is located.
• IU Box service for storing and sharing files
• More advanced users might want to consider using a revision control system, such as darcs or git, or tmux for terminal sharing.
  • On GitHub:IU, you can set up a private project and make your partner a collaborator (if you know git).

Other

• Pair Program with Me has a good list of tools and other resources
• Not recommended tools in Canvas:
  • Collaborations: Google Docs, EtherPad. I do not recommend these for pair programming, as they are fairly limited. They can be very interactive, but you don’t want your program to be a word processor document, and there is no provision for voice communication.
  • Conferences: Big Blue Button. It seems very hard to get this to work. But if you can get it to work at all, it might work very well for you.
• Slack/Screenhero looks like it might be worth considering, when they get the two products integrated, but as of 10/12/2015, they’re not integrated, and they’re not accepting new standalone Screenhero accounts.

Review Questions

Check your understanding:

1. What is the driver’s role?
2. What is the navigator’s role?
3. When should the pair programmers switch roles?
   • Comment: It’s largely up to the programmers to decide this, and it can be after an interval of time, or after an event such as something accomplished. However, in this class, I would recommend switching no less often than every 30 minutes.
4. What are some of the advantages of pair programming?
5. Disadvantages?
6. Things to do?
7. Things to avoid doing?
8. What are the logging requirements for pair programming in this class?