No Silver Programmers

Mon 14 January 2008

Someone who should know better gave a commencement address based on the premise "5% of programmers are 20x more productive than the other 95%." This is utter BS and it's important to say so. First, as boring as it may be to say "we don't have the data," go to and find me a peer-reviewed study of individual programmer productivity among professionals not students. I'll wait. What did you find? 1992's Watts Humphrey study? DeMarco's 1989 references to Coding Wars (the source for Peopleware and the likely source of the misquote in the commencement)? Maybe 1981's work by \<a href=""" target="_blank" rel="noopener noreferrer">Barry Boehm? The literature sucks. Anyone, including me, who tells you anything about software development productivity is telling you beliefs, not science. Understanding that is vital: the entire agile revolution is based on revisiting cost assertions taken as gospel. "What if the cost of a change didn't increase over time?" That question is why the practices followed by the best software developers today have little in common with the practices of ten years ago.

So, accepting that everything anyone says about this is anecdotal...

Do programmers vary in their productivity? Absolutely. Is there a small percentage of programmers who are very much more productive than average? Absolutely. Are they 20x more productive than those not in their ranks? Absolutely not. The numbers quoted in Peopleware strike me as most realistic: the best are near 3x median and 10x worst. In other words, the significant thing is not that some professional programmers are awesome, it's that some professional programmers suck.

Doesn't that explain your world better? Have you ever met someone 20x better than you? Seriously, a day to do what you could produce in a month of undistracted, phones-off, heads-down programming sessions? Of course not. But have you met someone who's 5x worse than you? Who you say "It took you a week to do this?" I'm going to guess yes.

That incompetents can stay in the profession is not nearly as mysterious and fun as a secret society of magical programmers. It's a lot more gratifying to think "I've never met anyone 20x better than me, so therefore I'm part of the elite," than "What does it mean that Bob and I have similar titles?"

Programmer productivity is essentially code creation: develop a function that satisfies specification X. I love code creation; I used to run a newsletter called "Those Who Can, Code." I write software to help me deal with stress. But code creation is not what spells the difference in software development productivity, for which I absolutely believe that teams can achieve a significant multiple (perhaps 10x) over median productivity.

Software development productivity is the rate at which you deliver value to the client. If good data on the productivity of code creation is lacking, good data on software development productivity is essentially non-existent. It's extraordinarily difficult to measure. Measuring satisfaction is an insufficient proxy, because satisfaction will tend to be a delta from the last experience, not an absolute.

There are only a few things we can say with certainty about software development productivity:

  • We don't generally do a great job at it
  • Processes can improve it, if the processes are a good fit to the team
  • Tools can improve it, if the tools are a good fit to the team
  • It is always a people issue

Now I've come full circle to agree with the conclusion of the commencement address.


What does the actual sparse data say? This is the graph from DeMarco's Coding Wars paper, the graph that is generalized in Peopleware (where the probably-significant shading of COBOL entries is missing):

(Remember "good" is to the left, not the right!)

Pretty shaky foundation for the whole damn super-programmer myth, wouldn't you say?