by five minutes. So instead of our lone wolf’s 45 out of 90 minutes in the zone, the pair is now concentrating (i.e. working) for 60 out of every 90 minutes. Let’s say our day has five of these 90-minute cycles. Two lone wolves would each do 225 minutes per day or 450 between them, while in comparison the pair is doing 300 minutes a day.
Before you run off to confiscate the kettle and shut down mail accounts, remember that development is a thought process, not manual labour. A wise project manager once complained to me: “I can’t get them to think any faster.” So can two individuals working separately do more thinking work than two collaborating? “I think not, Watson.” The rigour and quality of the pair’s thinking if they are well matched, will be much higher.
The litmus test is to ask if we use pair programming for building web applications for our customers when we work on fixed price work. Well, first off, we use a story-point rate for pricing most of our projects but that’s the subject of another article, essentially think of it as a fixed price, just for very small pieces of work. We do use pair programming for this type of work, not as religiously as we should, but most of the time. There are instances where our front-end developers would prefer to do battle with IE6 on their own and the system administration tasks are not (yet) test driven and shared by the whole development team. On the whole we try to do all our development using pair programming, and where we don’t manage this we use near-programming, our term for two developers sitting side by side and working on their own things but helping each other and sharing what they are doing. We certainly do not see pair programming as an expensive luxury, we see it as a way to increase productivity and code quality, which is one and the same thing really.
We embrace the productivity gains that we see from pair programming and structure our development environment to accommodate it as much as possible; all our new developers do a paired coding test to ensure that they can fit into this way of thinking. We have pairing stations with 30” monitors, dual keyboards and mice, flat fronted desks and
Scrum Masters that encourage pairing.
Pair programming’s benefits stretch beyond productivity and quality. It is easy to identify those developers in the bottom quartile if they are pairing with stronger developers, and lift their performance. Sharing knowledge or “amplifying learning” as Mary Poppendieck terms it, becomes a fluid part of the working day. Pockets of knowledge held by key individuals, and their protection of it, is a danger in any business and pairing is one method of removing this.
The many other benefits of pair programming should resonate well with customers, if communicated well. Projects will ultimately be shorter and bugs in production much lower, allowing maintenance to focus on feature additions rather than repairs, which for developers, as well as customers, is a much more rewarding way to spend time on the latter stages of projects. Customers now more than ever want certainty on costs and low risk on projects, budgets are lower and there are no longer bottomless pits of cash to hurl at problems. Pair programming is a useful tool and is very powerful if fully integrated into the development process. Time should be taken to explain these benefits to customers in detail, and not in a defensive way to justify costs.
If you are looking