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.
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 (http://en.wikipedia.org/wiki/Extreme_programming). 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:
- You learn faster.
- You transfer domain knowledge,
- You Increase productivity.
- You Increase quality of code.
- 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:
- There is a loss of developer creativity
- Depending on the pair, it’s possible to lose productivity instead of fostering it.
- 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. http://accu.org/index.php/journals/1395
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:
- 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.
- 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.
- 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:
- trivial bug fixes or
- 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.