The recent Forbes article “The Rise of Developernomics” by Venkatesh Rao promotes the idea that excellent developers are an order of magnitude more productive than median programmers, while terrible developers are an order of magnitude worse. This is a widely held belief in the developer community, but is almost certainly a myth. The few studies that have tried to quantify programmer talent have often used students as subjects, have almost always been tests of relatively short-duration programming tasks, and support order-of-magnitude differences between best and worst, not best and median.
I’ve discussed this before, but it’s important to revisit since the claim has such radical implications. A 10X factor in productivity is an extraordinary claim: It’s one day replacing a two-week sprint; it’s five weeks of work substituting for a year. If such a superprogrammer gets a cup of coffee, it’s as if a perfectly competent coworker spent an hour off-task. And the claim is not that such advantages occur in specific tasks or contexts, but that such advantages are inherent in the superprogrammer and extend day-to-day, month-to-month, year-to-year.
It is like the difference between a regular doctor and Dr. House, or between a precinct detective and Sherlock Holmes. If “10X” is really the way it is, the industry must adapt its teams and development processes around these superprogrammers. It implies that hiring is extraordinarily important: Companies must avoid hiring people who are “just” 2X or 3X better than median, because a 10Xer might walk in the door any time.
It implies that experience with tools or libraries is irrelevant: After the week or so it takes a superprogrammer to fully master a new programming platform, their superiority will emerge again. It implies that teams should adopt the Chief Programmer Team model, in which the superprogrammer is not simply first among peers but the centerpiece of all development. It implies that median software development salaries should stabilize or decrease over time, since median programmers are commodities, while the comings and goings of superprogrammers drive productivity. Investing in training programmers is pointless, as their overall contribution is minimal. This doesn’t seem to accurately describe, to me, the software development industry.
It seems to me that a more accurate distribution of talent shows significant “positive skew.” Excellent programmers can be said to be arbitrarily more productive than very bad programmers, because worse-than-median programmers can range from the merely sloppy to the literally non-productive to, in the worst cases, actively counter-productive (with their flailing making things worse). It’s not very revealing to divide by zero. But once one gets better than median, developers start to face headwinds: increasing complexity, the vagaries of human communication, organizational overhead, etc. Although it’s certainly true that in specific tasks or areas one sees 10X advantages, these seem to me to invariably be context-sensitive (Adam wrote the library and is a thorough master of it, Barbara knows how to use a parser generator, etc.).
Over long time periods and the varied tasks that typify enterprise development, it seems to me that median developers are pretty darn good and that excellent programmers might be more like 2X-3X median programmers in their long-term productivity. I’ve been accused of being disrespectful of excellence with this statement, but I don’t see it that way: One doesn’t demand an NFL running back to have 10X touchdowns to be considered a star, or a baseball player to bat in 10X as many runners to be hailed as excellent.
This skewed distribution, if true, has different implications. Hiring is still critical, but what’s really important is not hiring superstars, but avoiding (and firing) the bad programmers who can drag down average productivity. If software excellence is a relatively low multiplier over median performance and is context-sensitive, today’s median programmer might be tomorrow’s excellent programmer (and, to be sure, last year’s triumph is no guarantee of this year’s). If development productivity is context-sensitive, then training and exposure to a wide variety of contexts is a wise investment. If everyone on the team might have an advantage on any given day, collaboration, mutual respect, and shared code ownership will lead toward higher quality and productivity.
Now that does seem like a description of the industry I know.
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
