Bad Programmers Are Not Good Programmers Who Are Slow

In response to “No Silver Programmers,” a commenter points out:

Say I’m a pretty good developer and there’s this guy who is 5x worse than me, meaning it takes him a full work week to finish what i will finish in a day.

but then, what happens when it has 3x as many bugs, and it takes him 5x the time to fix each one?   suddenly we’re at 15x for the bug fixing phase.  and actually, it should take him more than 5x as long to fix each one — fixing bugs is much harder the more there are in the same code, and harder the longer it the time between writing them and finding them.  (and think about how much more time occurs between writing a bug and fixing one for this guy compared to me — he has 3x as many bugs, often blocking other bugs from being found and always blocking other bugs from being fixed, and he takes 5x as long to fix each one…)

and it doesn’t scale linearly when we look at code that will take me a month.  that’s going to take him more than 5 months.  his design mistakes will pile up and his buggy code will pile up.  something that takes me a year he may simply be incapable of doing.

Yes. Further, a team with him on it will require more coordination than one made of average-or-better developers. A 90% finished system will suddenly reveal a crucial weakness because of his work violating encapsulation or somesuch.

Bad programmers are not good programmers who are slow. They are actively counter-productive to the team.

This is another great point why, to improve your team’s productivity, it’s important to focus not on the hope that you can discover a magical super-programmer but on rooting out incompetence.

No Silver Programmers

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 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?