Back Home


Waterloo Co-ops test out Pair Programming.

Pair Programming – Waterloo Co-op style.

Chris and I will be spending the next four months at TWG as part of our Waterloo Co-op program. We”ll be focusing on mobile software development. Two weeks in, I can say that we’re well integrated into their team-based approach to web and mobile development, that we’re being challenged, having fun, and learning a lot as we go. Here’s our first post on a very timely topic – Pair Programming.




We Arrive.
As we strolled in for our first day of work, Andres, Dom and Jack sat us down, and with solemn faces, told us that Chris and I would be the lucky guinea pigs in a programming experiment. The experiment was going to be on Pair Programming, a style of programming that hails from the Extreme Programming and Agile Development canon ( Both the company and we were relatively new to the Pair Programming concept (or as some would claim.. a dogma).

Here’s how Pair Programming works day to day:

1. Take a pair of developers and give them one development machine at a single desk, with two chairs, and let them code together as a cohesive unit.

2. One developer is the driver – that’s the person at the keyboard typing in the actual code.

3. The other developer – the navigator – reviews each line of code as it’s being typed in.

4. Constant communication; as the navigator reviews each line of code as it is being entered, they are able consider the strategic direction of the work and foresee any future problems that may need to be addressed. We noticed that pair programming can be quite noisy.

5. Generally the roles are switched frequently; Chris and I exchanged roles roughly every half-day.

Pros and Cons
Before starting, to give ourselves the best chance for success, we scoured the internet for the best practices on pair programming. It didn’t take us long for us to find these two scintillating articles on techcrunch:


Great, it’s a love-it or hate-it relationship. Fortunately, a quick survey of our peers who had worked with pair programming found that most of them were in favour of pair programming. Both of the articles above raise solid points on each side of the debate. Those who swear by pair programming claim the following:

  1. You learn faster.
  2. You transfer domain knowledge,
  3. You Increase productivity.
  4. You Increase quality of code.
  5. The overall cost of developing software is lower

So you take two developers, sit them so they are rubbing elbows, take away one of their machines and magic happens? Well sign me up! But wait… what’s the catch? The other article claims that:

  1. There is a loss of developer creativity
  2. Depending on the pair, it’s possible to lose productivity instead of fostering it.
  3. There is a higher overall cost

If you’d like to read a more in depth account of Pairing, this article has a good blend of depth and accessibility.

Pairing works… for the most part.
Two weeks (or one full sprint) later, we can say that it works for many aspects of software development. In this specific case, we were picking up on an existing project, and we knew nothing about the code base. Pairing on the project allowed us to ramp up very quickly on what the code was doing, by talking it through between each other. It also meant that when a senior developer walked us through what had been done previously, there were two sets of ears and eyes to follow along and catch all the key learnings.

Pairing on many tasks turned out to be super beneficial:

  1. We were able to quickly bounce ideas and solutions off one another allowing us to quickly eliminate which ones would not work. Many times this saved us from coding ourselves into a corner only to realize the solution wouldn’t work.
  2. Having another set of eyes looking at your screen not only forces you to write better/cleaner code, but also prevents you from tabbing to one of your social networking windows, keeping productivity high.
  3. We noticed the details. Pair programming partners are great at catching typos in the code.

However, we also found that pair programming on smaller tasks often wasn’t required. Things like:

  1. trivial bug fixes or
  2. changing assets within the application,

In these scenarios, we found that switching to a side-by-side approach (a concept buried at the bottom of the beneficial article above), where we divide and conquer the tasks at hand, was much more efficient. Using this approach, we’d complete the work and then check the work of the other developer before any code was committed.

How does Pair Programming fit into TWG
While we’ve only done one sprint of pairing, and we see the benefits, we can already tell that it will be a challenge to determine just how much pairing and how much side-by-side (or even solo) coding should be done in future sprints. The past sprint was about 70% pairing and 30% side-by-side programming, but next sprint could easily be 20% pairing and 80% side-by-side — it depends on the stories and tasks at hand for the current sprint. Perhaps our Sprint planning sessions should take this into account, and the stories and pairing strategy could be set early, but re-evaluated during mid-sprint reviews.

In the end, we’d say that pair programming was beneficial, but that 100% pairing wasn’t the solution that worked for best. As with many things, it’s not surprising that somewhere in the middle — a goldilocks approach between pair programming and side-by side programming — looks likely to produce the best fit. We’ll update you later this summer as the experiment continues.

One Response to Waterloo Co-ops test out Pair Programming.

  1. Andrew says:

    Sounds cool to be guinea pigs, (if there is a part II) I’d be interested to hear if you use any software for double keyboard hooked up to 1 pc. I had heard the company hashrocket also does pair-programming.
    Obie Fernandex (the founder of hashrocket

    had a post about it in 2008. I alway thought it sounded awesome, I like the idea of having 2 keyboards hooked up to 1 computer (they used something called teleport for osx)

    We don’t practice it where I work (out in Hamilton), but whenever the senior dev rolls his chair over, to transfer some domain knowledge, I have noticed that:
    1) things get done (with corrections), and
    2) both of us learn something while having a good time.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>