Top Programmers are 10,000X’s more productive than average programmers
According to Nathan Myhrvold, former chief technology officer at Microsoft:
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
‘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
posted by Shawn Arney at 11:07 AM
3 Comments:
Wow Chris! You are right on target! Avoiding the reinvention of the wheel by purchasing third-party components is right on! I agree with your analogy of super-programmer status. If you can tap into an API without having to write it from scratch... viola, you have achieved superior productivity for that piece of the software.
Now, once we have tapped into the third-party components, now what? We are still dumb and average programmers... somewhat akin to monkey-see--monkey-code. Even with all the best third-party components, we could have a maintenance beast that is hard to maintain and is a resource hog.
I think this is where we could introduce eXtreme Programming. We could make the jump to pair-programming. Let the team collaboration help build a stronger and better skilled team.
This would jive with you ideas about the need to build trust and collaboration -- sharing the knowledge. I think pair-programming in particular will help us move to the next level of productivity beyond code-reuse gains.
Let's talk about pair-programming in the next blog. If you have any other ideas, let's talk about them too!
This comment has been removed by a blog administrator.
My favorite is ”16. Chuck Norris doesn’t use web standards as the web will conform to him.”
supplements
Post a Comment
<< Home