Top Programmers are 10,000X’s more productive than average programmers
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.
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.