Extreme Programming

Learning Objectives#

Describe pair programming.
Articulate the benefits and drawbacks of pair programming.

Lesson Overview#

Topic	Type	Timing
Opening	Intro	5 min
The Good, The Bad, And The Ugly	Lecture	15 min
Pair Drawing	Independent Practice	30 min
Wrap Up	Conclusion	5 min

Opening (5 min)#

We learned about pair programming in the context of the principles of extreme programming. Can anyone recap the definition of pair programming?

Pair programming refers to two people working on the same code using a single computer. The latter part (using only one computer) is important, because pairing is about actively collaborating and not just two people working on the same project or sitting next to each other.

Can anyone describe what each person in the pair is doing during this process?

The driver is the one sitting in front of the keyboard actually typing the code. The navigator sits next to the driver and reads the same screen. The navigator is there to talk through ideas, direct the driver, and think about how the code that's currently being written fits into the larger project.

We'll be doing our big course projects, as well as lots of smaller labs and activities, in pair programming, so it's something you'll get more and more familiar and comfortable with over time.

The Good, The Bad, And The Ugly (15 min)#

As with anything, pair programming is not without its advantages and disadvantages.

Before we start, turn to a partner and brainstorm:

The advantages of pair programming.
The disadvantages of pair programming.

The Good#

There are several advantages to pairing:

It keeps everyone focused on the task at hand. When you're working alone, it can be easy to get distracted (e.g., by email or a shiny new JavaScript framework), but it's much, much harder to switch to Gmail when someone's sitting by your side and reading your screen.
Successful pairing should yield a productive feedback loop in which each person helps keep the other focused.
Another advantage is that the navigator can catch a lot of small errors immediately (typos, missing semicolons, incorrect variable names, etc.); it's faster and easier to fix bugs at the moment they're introduced than at any later point, so this ends up being a big win. Plus, as the saying goes, given enough eyeballs, all bugs are shallow.
Pairing is great for knowledge transfer and can help with everything from learning a language to picking up editor or command line tricks.

The Bad#

It's good to make sure you have similar (or at least compatible) goals before you start pairing. If one person thinks the goal is to learn Python and the other thinks the goal is to fix a bug as quickly as possible, you could run into friction. Making sure you're on the same page (or at least know where each other is coming from) helps everyone get what they want.

The Ugly#

Sometimes you'll hit a wall. For example, you could run up against a concept neither person understands or not know what library works best for your project. In these cases, it'sOK to take a break from pairing. If you do this, you should timebox it, e.g., "Let's spend 15 minutes on our own researching what the best library for this is and then report back with what we've found."

The important thing is to explicitly agree to take a break and set a specific time when you'll check back in. The one thing you should not do is pretend to keep pairing but really default back to just working next to each other. It's easy to do this and waste hours without even noticing it.

Another rule of thumb is to switch roles (i.e., driver and navigator) regularly; every two hours at a minimum, and ideally even more frequently. Switching regularly helps with knowledge transfer, ensures that both people get to drive and know what's going on, and helps keep everyone energized.

Pair Drawing: Superhero Vehicle (30 min)#

The objective is to draw a vehicle suitable for a superhero. You can define any superpower(s) you want for your superhero and can make the vehicle as flashy and functional as you can.

You'll have five minutes to define you superhero. You must give them a name and define at least two superpowers.

You'll draw one vehicle each by yourselves with a marker. When the five minutes are up, pairs will define a new superhero and draw together.

You and your partner should begin by defining a new superhero with a new name and at least two superpowers. These may be a combination of the superpowers you've already defined. Each member of the pair should have a different colored marker to show their contribution to the drawing.

Debriefing#

Share your drawings to the class and discuss the following questions:

How did it feel to work with a different partner?
How different are the results between the drawing you did on your own and the drawing you worked on together?
What did and didn't you like about drawing alone or in a pair?
Were there any differences in how you worked with a new partner?

As a group, discuss the following questions to share key takeaways:

What was easy or hard about this way of working?
What could have been done to improve your results?
Did you discover any additional pros and cons of pair programming?

Conclusion (5 min)#

Pair programming is something you'll come to be intimately familiar with during this course. This was just to give you a taste of the concept and some tips and tricks to make it work most efficiently for you.

Let's quickly recap some key terms and ideas:

Pair programming
The driver
The navigator
The advantages and disadvantages of pair programming