Is it just pushing up developer rates and doubling demand?
The cynic in me applauds the genius of the global developer community for inventing a way of working that requires twice the number of people to do the same amount of work – Pair Programming. Doubling demand on XP projects means more work for developers and reduces the pool available for traditional projects – rates go up and more jobs are secured. Is this the same genius as those 70’s marketing execs that added “step 3 - repeat” to double shampoo consumption and therefore sales overnight or are there genuine productivity gains to be had for consultancies and customers? I said I was being cynical, but there is some truth in this and it is a view held by some of those that pay the bills, customers.
In his book Peopleware, Tom DeMarco studied developer productivity and discovered that the top quartile were 2.6 times more productive than the bottom quartile. That’s a significant saving, more than double the cost of a pair. So, can two bottom quartile developers pairing be as productive as one top quartile developer? Probably not but it’s a complex equation with hard-to-quantify variables – in reality the truth of the benefits lie in the sum of the parts.
Pair programming has its roots in XP and there are good arguments that its use leads to more productive developers and defects are found earlier in the development cycle. It can easily be shown that a defect caught early is exponentially cheaper to fix than one found later. The cost of finding a missed edge-case and creating a test, then a couple of lines of code, could be as little as 10 minutes. If this edge-case is not spotted and code is promoted into production of a share trading back-end, burned on the EEPROM of a jet’s fly-by-wire steering control system or shrink-wrapped onto retail shelves the cost is dramatically higher! This cost isn’t just financial, it’s reputational, and no business in the current climate needs a dent in its reputation.
Even pre-production there are savings to made if defects are caught before promoting code to staging environments. Once in this environment, there is duplication of effort, delays whilst the fault is tracked down, fixed, re-promoted and regression tested. The cost is going to be greater than 10 minutes effort, perhaps conservatively a delay to four people of an hour each – that is a 24 times cost saving.
A greater saving achieved through pair programming that is harder to quantify, is that of how long it takes a developer to get into the “zone”. The zone is that phase of deep concentration where the developer’s brain is solely occupied with solving the problem at hand. They are in the code – the state of the running application, values of variables, possible scenarios, expected outcomes are all in the forefront of the mind. The arriving emails, half-eaten sandwich on the desk, ringing phone at the next desk and interesting article in the browser window are all forgotten and development work in its
purest form is happening.
A lone wolf, sitting at his desk may get into the zone for about 45 minutes every hour and a half. It takes about 5 to 10 minutes to bootstrap the state of the application into the brain and step through to the point of problem solving and coding. Once the developer’s trance is broken, the brain starts looking for relaxing activities, anything from e-mail to web browsing, making a cup of tea or speaking with a colleague. As a side thought, one day someone will study why
people with mild Aspergers syndrome make better developers - I would suggest they can stay in the zone longer.
With pairs a strange social interaction happens that reduces downtime. Some relaxation activities are impossible because the computer is shared – checking email and browsing the web for example would be as socially unacceptable as sharing a toothbrush! Developers are motivated by problem solving and doing this through teamwork is often more fun than going solo. In my experience downtime in pair programming is greatly reduced and the time that two people can remain in the zone is increased. Conservatively the zone time would stretch by 10 minutes and the down time would reduce by 10 minutes. One could argue that the bootstrapping period may increase, let’s be generous and say 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 to dramatically increase quality, have a more productive, happier development team and reduce risk on your projects, find two amenable developers and give pair programming a try.
About the Author
Richard Stobart is managing director and founder of Unboxed Consulting, a UK-based consultancy formed in 2005 that specialises in the use of agile methodologies and Ruby on Rails. He formed the company to be all the things that working for others wasn’t and has a career in software development spanning 18 years, working on mainly large enterprise systems across a number of markets including logistics, media and finance.
About Unboxed Consulting
Formed in 2005, Unboxed Consulting is a UK software development consultancy producing exciting consumer and business facing applications for some of the largest brands in the UK across sectors as diverse as new media and financial services. It specialises in Ruby on Rails and uses the latest Agile development methodologies to inspire customers and development teams to bring creativity and innovation to every project large or small.
