Monday, June 13, 2005

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,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.

Thank you,
Darshan Arney


Blogger Chris said...

The implication of both your blog and the article you quote are that super-programmers are simply in a groove when they are working at super capacity. Can this really be the case? It has been my experience, that when I am in the “groove” I do get much more done, but this is usually just attributed to my knowledge on the area I am working in being complete. Comparing this super-programmer work capacity to an area that I have to research or work through the logic towards my goals on an hour by hour basis and you may be at near standstill in programming. It takes time to develop an understanding of what you need to accomplish, but once you have your arsenal full of ready to be used code, then super-programmer (the alter ego of every would-be programmer) can take over.

Consider a project in which I need to interact with my enterprise’s active directory through LDAP. The first programmer that had to perform this activity probably bumbled through it for several days, maybe even weeks. They got a prototype running and showed the boss, “Look what I can do.” It took 30 minutes to complete one query and the boss looks at them with a look of unbelief. “You did it? Are you kidding me, this is fantastic!” Six months later the programmer has refined the code and taken out the looping code that was slowing things down. Now the query runs in milliseconds, and the code has been packaged into a DLL.

This one piece of code from this point on will extend this programmers ability to perform in this one area in a near limitless capacity. “Hey Joe, we need to work with AD, what have you got for me?” They tap into Joe’s DLL and they are done in seconds. Built correctly the code can be used anywhere they need to; there is no need to re-invent the wheel.

Consider another side of the coin. John and Joe are competitive programmers vying for the same position. The company asks John about experience with AD, of which he has plenty. They ask Joe, and likewise he has plenty. If they hire John, John will have to hard code an AD interface into their app. If they hire Joe, Joe can tap into his DLL and is done in mere minutes. John takes two days to complete his AD interface for them. Now by all accounts John is the better programmer because it took him only two days to complete a working AD interface. Joe on the other hand took six months to grind through all aspects of the AD DLL, but has ultimately benefited to the “nth” degree when he is going to use this DLL. No need to rewrite this code again, it is done. The only exception to this is if the coding environment changes, then the DLL must be re-worked to give the same benefit and thereby extending its lifecycle.

Each of us has probably had similar stories and experience in our own field. The real key to building a successful team is not to simply hire average programmers and let them have at it, but rather to build a trust and collaboration between your programmers. If I have a DLL that will save the company 10,000 hours work and takes only an hour to install. I have just become a super-programmer. If I share my DLL with a team I trust, we have all just become super-programmers.

I find it hard to believe that any single person starting from scratch on a blank machine can achieve super-programmer status. We have to be talking about previously coded and reusable code to seriously consider the figures the original article is mentioning. Even if we are talking about someone who can achieve that status working from scratch, I would seriously doubt that they are not using some form of existing code (I just don’t think anyone can type that fast). ;)

On another note, consider all of the DLL and ActiveX controls out there for sell. If it took a development team 10,000 hours to develop an ActiveX component, and it installs in less than an hour, wasn’t it a good purchase? It all depends on the price, right? Say I get the ActiveX control for $100, and we calculate our team can build the same control in 50 hours, is it still a good deal? How big is our team? If it is more than one person who is making $2 and hour then it is worth it right?

Ultimately programming must be metered out with cost effectiveness of development and availability of alternative sources. The other side of the coin here is when considerations must be made for say security, or absolute certainty of bullet proofness; can you ever trust a 3rd party app to do its job? Yet if we can pull in completed code through a DLL or other application; does the cost of the 3rd party product alleviate our inability to program that aspect of our application?

All of this takes knowledge of what is out there, what requirements you have, and what your team can do most effectively with their time. Just because we can fully develop it in house, the question is should we?

- Chris

3:03 PM  
Blogger Darshan Arney said...

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!

9:46 PM  
Blogger Darshan Arney said...

This comment has been removed by a blog administrator.

7:47 PM  
Blogger Sara Reid said...

My favorite is ”16. Chuck Norris doesn’t use web standards as the web will conform to him.”


5:40 AM  

Post a Comment

<< Home