I am a sucker for rationale. I’ve been struggling with rationale on the Extreme Programming (XP)-practice of pair programming for quite some time. What at first looks like one person writing code, and the other one watching, has admittedly been very counter intuitive to me. Let me share my current thoughts of benefits and disadvantages of so called pairing.
Disadvantages of Pair Programming
Don’t four hands produce more code than two?
If you are a carpenter, you can hit more nails with four hands than with two. If you are a brick-layer you can lay more bricks with four hands than with two. If you are a developer you can write more production code with four hands than with two. Or wait. This is based on the assumption that the bottleneck in software development is a mechanical one ; the speed of which you can type on the keyboard. My 10 years as a developer and 5 years as a program manager tells me otherwise. The bottlenecks in somewhat innovative projects (non-repetitive) rarely or never include typing speed. Bottlenecks do include hesitation (doubting your own solution), introducing bugs and having to go back to fix it, suboptimal design that deserves a refactoring, lack of needed knowledge for the task, loss of focus and so on.
A small disclaimer before I go on : We have not been experimenting with Pair Programming for more than a few months, and my above observations are based on observing teams develop from a managerial point of view and from reflecting upon my own coding habits as a team member.
Benefits of Pair Programming
The speed of learning in pair programming is overwhelming. Once you enter a topic one party has more experience in, you are in for a ride. I have never experienced learning at such a pace as when this occurs.
Bugs are cheapest when they are prevented from being introduced with measures that does not put restraints on your risk-taking and innovation. Pairing keeps you innovating, and will still help you spot errors more frequently. You will be more critical of your own code, and you will have someone constantly looking for possible improvements in your code, such as stopping a bug in the making, or having an idea for an even better test.
Pair programming is a dialogue between two people trying to simultaneously program, and understand how to program better.
Pair programming forces you to put words to your thoughts. This will through constant practice improve your skills in articulating your ideas.
The responsibility on one single programmer can be huge at times. It is relieving to carry the load together. A teams strength and robustness is greater than the sum of strengths.
When exhausted for ideas or new angles, it can lead to hesitation to implement what you suspect is a sub-optimal solution. The union of ideas and angles between the two developers makes this a rarer incident, and the resulting discussions will usually help remove the knots causing hesitation.
From a managers point of view, a migration of people between project modules, and even between projects, becomes vastly easier. This is a dream come true. Nobody is the sole “owner” of code anymore, and developers can move more freely between code sections and projects, simplifying the complex task of resource scheduling. Starting out on unfamiliar code means that you should be pair programming with someone with a lot of domain knowledge in the start.
How to do pair programming
Pair programming is two people using one keyboard to write code. Here are some important best-practices to go along with that description.
- Choose a suitable partner for pair programming the given task during the daily scrum.
- Sit side by side with only one keyboard and one mouse. Both should have a good view of the monitor.
- It must be easy to slide the keyboard from person to person. Switch roles from typer to observer every so often.
- Discuss and have a good time.
So, these are my reflections on the subject so far. I will be sure to update you (RSS) on any changes of opiniton as we continue to improve our development practices.