Since Squad is particularly well-suited to facilitating strict pair programming, we’ve touched on the subject several times here. A recent Wall Street Journal article also highlighted several different programmers’ experiences with the method. We’ve also mentioned, in rather more nebulous terms, a sort of “collaborative programming” that is also possible, without exactly sticking to the rules of pair programming. While I was doing a semi-regular review of academic literature regarding programming best practices a few weeks ago, I finally stumbled upon some research that gives this nebulous collaborative programming idea a name: side by side programming. If you use either of these techniques, or are considering using one, here’s a quick look on the main points of each.
The basic setup for pair programming is that there are two roles: the driver and the observer. The driver controls the mouse and keyboard and actively writes code. The observer spends his time watching the driver’s code, points out mistakes, and spends time contemplating possible alternative approaches to the problem at hand.
The pair should switch roles every so often, to keep each team member sharp and focused. The exact optimal interval is a topic of debate and probably varies for each team, so if you are exploring the pair programming technique, start with something you can each agree on, and adjust according to how you feel the time works for your pair and current project.
There are different philosophies regarding how much time a programmer should spend pair programming; some companies ask programmers to work in pairs all day, every day, while others find it to be more effective in smaller doses.
Side by Side Programming
Researchers have used the term side by side programming to describe programmers who work on code simultaneously but don’t adhere to the strict protocol of pair programming. Programmers using the side by side method are more likely to be physically located in different places, and this method more easily allows for a whole team to work on a document while maintaining an awareness of what colleagues are doing.
Because side by side programming does not have the strict protocol of pairing, it is somewhat easier to get used to and use quickly. Typically, a team using side by side programming would all be working on their own tasks until a team member asks for help or just another set of eyes. At that point another colleague joins the first wherever he or she is in the code and they work through the issue together, whether they are in the same room or across the world. Once the issue is resolved, everyone goes back to his own task. This flexibility makes side by side programming easier to integrate into the team’s workflow, but doesn’t have pairing’s advantage of constant error checking and knowledge distribution.
If you would like to explore these methods of programming, you might want to check out a few of these resources.
Types of Cooperation Episodes in Side-by-Side Programming by Lutz Prechelt, Ulrich Stark, and Stephan Salinger (2010)
Pair Programming vs. Side-by-Side Programming by Jerzy R. Nawrocki, Michał Jasiński, Łukasz Olek, and Barbara Lange (2005)
Distributed side-by-side programming by Prasun Dewan, Puneet Agarwal, Gautam Shroff, and Rajesh Hegde (2009)