By Nathan Donaldson
Tags: Agile , Development
Here at Boost we’ve been pair programming for a while, and seeing benefits in the form of cohesion and knowledge sharing, as well as the quality of code we produce when working in pairs. As part of the adoption of this practice I set out to research how pair programming has been working for other teams and how it can be used to improve the team dynamics.
For those that are new to the concept of pair programming: at its core, it’s when two developers sit in front of the same computer and develop code together. One programmer acts as a driver and the other as the navigator. The driver controls the keyboard and mouse and is concerned with the concrete tasks of coding, while the navigator reviews the code and thinks about bigger picture issues.
Pair programming came out of the XP Agile framework. You can find out what pair programming and other eXtreme Programming practices mean for product leaders in this post: The Extreme Programming customer: A product leader’s guide.
As Obie Fernandez explains in his article “10 reasons pair programming is not for the masses”, in order for pairing to work the team has to consist of developers who are committed to their work, and who are sociable and able to interact with other team members. Otherwise problems will quickly arise when you are working in such close proximity with other team members.
Few or no bugs: The first thing you will notice when pair programming is how few bugs are left in code produced by the pair. Pair programming is like a constant code review process, which is why typos or small details that a single programmer normally wouldn’t notice gets spotted almost instantly by the navigator, eliminating hours of debugging later on.
Code quality: The general quality of the code is also greatly increased. This is because while the driver is implementing the logic, the navigator is free both to spot errors and to think about the big picture and how it relates to the rest of the code.
Programmer productivity: When working alone it is very easy to get distracted by email, twitter, Facebook, and all the things going on within the office. When working in pairs, if you were to do any of those things it would waste the other person’s time, so pair programming is a constant reminder to focus on the work.
Knowledge transfer: In an environment where developers work alone, it can be hard to share knowledge because there often isn’t a time or place to do it. Pair programming involves constant discussion and flow of ideas on how to resolve a problem, and normally a pair can come up with many different solutions to a single problem. It’s also great in situations where you want to introduce a new team member, to get them up to speed very quickly with the development practices, coding style, git workflow and other practices the developers might use.
When: Although some of the development companies promoting pair programming suggest using it 100% of the time, in my own experience the intense focus and concentration that happens with pair programming can be draining over a full day. I suggest you pick the tasks that will benefit from having a pair work on them, rather than applying pair programming to every task.
Workstation setup: We have been using just one display, keyboard and mouse with great success but I would definitely like to experiment with two keyboards and see how the interaction between developers works out.
Rotating pairs: One important aspect is to let developers constantly change pairs, on a daily or weekly basis. This has several benefits: it helps develop a bond between the team members; the team as a whole takes ownership of the code instead of individuals; and knowledge sharing is increased by working with developers with different levels of experience and backgrounds.
