What is it?
Pair programming is two developers working together on a common task on a single machine, ideally with dual monitors, keyboards and mice. There are two roles in pairing: the driver and the navigator. The driver is focused on the tactical aspects (i.e. writing the code to get the task done). The navigator is focused on more strategic aspects (i.e. improvements in the algorithm, potential impacts to other components, etc…).
Why is it important?
- Improved software quality
- Reduction in software maintenance cost
- Improved productivity
- Improved business continuity (in other words, knowledge is spread across more people within your team and therefore if someone is out sick, on vacation or quits you are not as vulnerable)
How are those benefits realized?
I hate to start off by answering this question with a cliché but I can’t resist. Knowledge is power. One of the primary constraints we face in software development is our own ignorance. For us to be successful we have to manage it. The more we know the better we can perform. Consider the cone of uncertainty and how it represents the variability in our software estimates through the lifecycle of a project. We are at our smartest at the end of the project when we have the most information. Therefore, whatever we can do to reduce our ignorance by discovering the information we would normally uncover at the end of a traditional waterfall project earlier will allow us to be that much more successful in delivering quality software. In other words the act of obtaining and sharing knowledge allows us to achieve better quality software, improved productivity and business continuity. I will caveat my statement by acknowledging that it’s impossible to know everything and discovery everything upfront (that’s what the traditional waterfall approach attempts to do) but I do believe we can make more use of techniques such as “tracer bullets” to deliberately discover gaps in our knowledge.
Pairing allows two developers either of the same level or mixed to bring their knowledge and understanding of the functionality and the technology into a common medium, normally in the form of code.
This also addresses the 3rd benefit, improved business continuity. Knowledge sharing in a traditional waterfall organization occurs at the end of a phase or project when all the code has been written. Pairing promotes real time engagement and knowledge sharing in a more intimate setting. It also touches on the 3 commonly recognized learning styles (Fleming’s VAK model):
- Visual Learners – Those that learn through seeing pictures, handouts and other materials. They also benefit from observing demonstration.
- Auditory Learners – Those that learn through hearing information in the form of conversations (face to face or over the phone), podcasts, etc…
- Kinesthetic Learners – Those that learn through hands on activities. They learn best through experience.
A good pairing session will have a balance of conversation, observation and “doing”.
Instead of a 4 hour code review or presentation in front of 10 or so developers, it’s focused one on one time. It’s important to realize that the goal and objective of business continuity isn’t that everyone within the team can do everything or will know everything but to ensure “enough” people know to reduce the impacts of natural attrition and absences that occur within organizations.
The 2nd benefit, improved productivity may not be realized initially. In fact it may feel like less work is being done but it is part of the natural progression. Pairing is a skill. People don’t magically become great at pairing. It takes practice and time to develop like any other skill. What really drives the productivity is the learning that takes place as they engage on a common task. That learning can then be applied to future work.
In conclusion, pairing is a technique that can used to help manage knowledge within an organization and it is through the acquisition of knowledge and application of it that leads to higher productive teams.
Give Credit Where Credit is Due:
I want to clearly state that most of what I have mentioned above (if not everything) is not an original thought of my own but my own personal understanding through experiences ranging from presentation and seminars I’ve attended, articles I’ve read (see below) and developers I’ve spoken with. My intention in writing this is to help flesh out my own understanding and provide a means to share the knowledge I’ve gained through those experiences with my team and colleagues. The resources below are among many that have helped shape my perspective on this topic. I encourage all of you to reach them. =)
“THE LAWS OF SOFTWARE PROCESS A New Model for the Production and Management of Software”, Armour, Phillip G., 2004