Pair programming: when are two better than one?
February 11, 2011
Over the last few years, we have been developing a considerable amount of infrastructure to enable us to provide faster and cheaper solutions to our clients without sacrificing our high standards of statistical methodology and interface aesthetics. Although we have learned many lessons from this experience, one of the most poignant lessons we have learned are about the virtues of pair programming — the practice of having two programmers (a "driver" and a "navigator") collaborate on the same programming task at the same computer. The question is, when does it make more sense for two people to focus all of their attention on one task rather than having two people focus on two separate tasks?
(a) Reusable software. When you are in the throes of developing software, particularly software you intend to have several people use on a daily basis, it is very important to write high-quality code — code that has an intuitive and elegant user interface (the Python language comes to mind). For even the most experienced programmers, developing exceptional programmatic user interfaces can be difficult to do, let alone learn. Working with another programmer makes this process far easier. You can discuss what things should look like, how you would like to use the code in the future, and brainstorm ways to make things extendable for future use. Ultimately, these conversations save a lot of time that would otherwise be spent by an isolated programmer refactoring code to make it more usable.
(b) Crunch time. When a deadline is rapidly approaching or a project has an ambitious timeline, it is easy to think that the most efficient approach is to divide and conquer — split tasks between two programmers who can cross items off the list in parallel. The challenge with a divide and conquer strategy is that, inevitably, one person runs into a bug, usually at the most inopportune time, which can dramatically impact project timelines and even hinder the progress of the team. One of the biggest virtues of pair programming, particularly in a crunch, is that you minimize debugging time (to close to zero). While the "driver" writes the software, the "navigator" is constantly checking the approach and mentally considering possible errors that could arise. As a result, projects tend to stay on track and substantially reduce the variation in project time estimates.
(c) Teamwork. As with an author's "writer's block," stumbling blocks are unavoidable in programming; it is commonplace to run into a seemingly insurmountable problem and get distracted with other things (how many times do you check your e-mail every day?). These barriers not only significantly decrease personal productivity, but they also can serve as a distraction to colleagues. A benefit of pair programming is that you naturally switch roles — the "driver" becomes the "navigator" and vice versa — allowing teammates to solve each others problems and learn from one another. In our experience, this role switching also serves to keep the pair on task, ultimately making the team more efficient than you would otherwise expect.
(d) All the time. Are there times when you are not trying to write reusable software, or that you are not in crunch time, or that you would not benefit from learning from your peers? Probably, but our experience suggests that pair programming allows you to develop better code more reliably and productively.