Productivity Benefits of Pair Programming

Agile Programming prescribes pair-programming to enhance code productivity and quality. When two software developers sit at one computer to code, it is called pair-programming. With groups of developers, developers typically switch partners throughout the development process. Pair-Programming has been found to lead to a productivity loss of 15% for new development (Cockburn). When two developers sit at one computer to code and design, it has been found that they produce the work of two developers minus a productivity loss of 15%(Cockburn). This productivity loss is made up significantly though in Pair-Programming’s many benefits.

Pair-Programming produces higher quality code due to the peer-review effect and collaboration of two developers, resulting in fewer maintenance defects and less repairs on the field. According to Cockburn, Pair-Programmers are expected to have 15% fewer defects in their code as opposed to Solo Developers (Cockburn). This is significant because maintenance is oftentimes more expensive than basic development costs due to support overhead, developer intervention, and overall client dissatisfaction with buggy code. There is much to be said about a superior quality product that does not have significant bugs and rework. A fifteen percent upfront cost in development is more than offset by the maintenance savings.

However, the best benefit about Pair-Programming is the information sharing aspect. With pair-programming, developers are exposed to the entire application and get experience with all aspects of the product. On a complex and large project, this benefit is enormous and can be detrimental to the success of a product. Often with complex projects, there is a learning curve involved as each developer tends to specialize in their own unique tasks.

Developers do not necessarily know how to troubleshoot or fix a problem area of another developer due to this learning curve. If a developer decides to quit or is hit by a bus, there will be a significant hit to the project timeline due to the learning curve effect. However, Pair-Programming significantly reduces this risk by exposing all members of the team to each area of the project. Further, by collaborating across specialties, the strength of the development team grows. This is because by collaborating with others, developers learn new techniques they were unfamiliar with from their peers.

The team meshes, learns, and grows stronger technically and relationally as they work closely together. Each member of the team develops a solid understanding of how the entire project works and how each piece of the product works. Rather than having only a narrow view of their contribution to the project, they have an overall frame of reference to work from. This benefit will also produce a more holistic and complementary product that works well as a whole due to each programmer’s familiarity with each area. Pair-programming can be the key that unlocks productivity and quality in your software development.

References:

Cockburn, Alistair. “The Costs and Benefits of Pair Programming.” http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Resources:
Details how to Pair-Program http://www.pairprogramming.com/

Top Programmers are 10,000X’s more productive than average programmers

According to Nathan Myhrvold, former chief technology officer at Microsoft:

‘The Top software developers are more productive than average software developers not by a factor of 10x or 100x or even 1000x but by 10,000x.’

Nathan Myhrvold as quoted on page 14 of: Covey, Stephen: The 8th Habit: From Effectiveness to Greatness.

I e-mailed Nathan Myhrvold about the statistics used to back up his claim and here is his response to my unsolicited inquiry:

--
>From: Nathan Myhrvold [removed email address]
Sent: Tuesday, March 08, 2005 5:29 PM
To: darshan@[removed email address]
Subject: RE: unsolicited question -- on programmers being 10,000 times more productive

The general effect has been verified in a bunch of studies. The very best software developers are MUCH better than average or worst. This is particularly true for a complicated program. Whether the number is exactly 10,000X or not is harder to say - to get that precision you would have to measure it carefully, and would have decide how to measure. I was speaking colloquially when I said "10,000X" - it is not meant to be an utterly precise measurement.

Here is a site that quotes a more modest figure of 10X to 20X http://community.borland.com/article/0,1410,23174,00.html

I would expect that this is a big underestimate when you get to something really complex - the difference between somebody who "gets it" and somebody who doesn't is huge.

Nathan
---

In browsing the article listed by Nathan Myhrvold, it becomes apparent that it is not necessarily the star programmers that one should hire. Star programmers have a tendency towards elitism that precludes them working well in a team environment.

Accordingly, one can make efficient use of very average programmers to create overall productivity gains on the scale of 10-20X’s. Further, average programmers are easier to hire, retain, and are less costly. Small changes in the team environment of average programmers can lead to big overall productivity gains.

Where is this leading? Well, productivity improvements of only 5% among a team of 5 programmers leads to an arithmetic team performance gain of 25%.

What is a performance gain of 25% in real dollarized cost savings? This benefit depends upon your organization and cost structure.

This 25% performance gain at the development team level, I will theorize, causes an exponential or geometric cost savings ripple across the teams linked to the software product ie: Quality Assurance Team, the Testing team, the delivery team, the Production Support team, etc. This is because with improved time to hand-off, leading to a shorter delivery cycle, it follows that more bugs/issues will be stopped sooner/quicker in the delivery cycle… leading to true cost savings.

Performance improvements then lead to exponential cost savings as the effects of performance improvements ripple through other departments. Of course, an overwhelmed QA team stuck in limbo can reverse all of this performance gain by holding up the development lifecycle.

It is therefore important when improving a part of the software development lifecycle to ensure that other divisions involved can take full advantage of this productivity improvement. Otherwise, the ripple effects of a performance gain will not be fully realized.

Software built in a team environment with multiple divisions involved in the software process, for obvious reasons, have the most potential for significant performance gains and cost savings benefits due to small improvements in productivity gains.

Thank you,
Darshan Arney

Programmer Productivity and Economic Rewards

In the last few months it has come to my attention that programmers can improve their productivity by astronomical percentage gains. I will follow in another article how these gains and what gains can come about. It follows then that the following conjectures may well be in-line (note these are conjectures and assumptions not proven facts)

If Software is one of the major areas where productivity gains can be astronomical as opposed to other careers, then the potential there is for unlimited monetary gains. Software may be one of the few areas where economic profits are possible long-term. Economic profits typically become zero due to competition. But, even in a competitive market, if productivity can be improved long-term, then long-term economic profits are still possible… The potential then for software as an incredible money making machine is there – even with competition. This is of course, only if productivity gains continue to outpace competition's lost margin.

Please comment and correct, I appreciate the debate!

Thank you,
Darshan Arney