Pair Programming - Is it just pushing up developer rates and doubling demand?


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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.