Steve McConnell defends the idea that there’s a 10X difference in productivity between programmers. Unfortunately, we don’t have a clear idea of what “productivity” in programming really means. It turns out even economists who study labor productivity have only a crude, high-level definition: output divided by input. For a business, this is fairly easy: revenue divided by expenses. If we narrow this down to programmers, we can say the input is a business requirement doc and the output is version 1 of the software. In this sense, productivity is defined as the cost to deliver software, where cost ($) is a proxy for time, number of devs, free sodas and massages, and whatever else is required. The steps for converting requirements into software are basically design and code. Design stands for stuff like gathering requirements, designing code, choosing technologies, etc. Code stands for programming, testing, configuring, etc. Of course, bad design leads to bad code, so design is more important than code.
To measure the “code” stage, one could give (and explain) detailed pseudo-code to a group of developers and time how long they take to write bug-free code. It’s fairly mechanical; people working like “sufficiently smart compilers”. Measuring the design phase is far more complicated. It depends on a person’s familiarity with a domain. There might be a way to grade people roughly (good, mediocre, bad), but not measure people precisely nor consistently. Furthermore, I suspect there’s something akin to Amdahl’s Law at work here. If, as I believe, design is far more important than code, then optimizing the code stage will have very little impact on overall project time. If coding from specs takes 20% of the project time, optimizing that away (infinitely fast) would yield at most a 25% improvement in project time (totalTime/designTime).
Of course, devs rarely “design” software up front. Instead, they use their programming language as an executable specification language with which to explore the design space. That’s a polite way of saying that most devs just hack up a half-assed solution. The design and code phase are mashed together, making it difficult to figure out which phase was really the bottleneck. But I’ll bet it would take nearly the same effort if devs were simply asked for a moderately detailed design. The point, therefore, is that good programmers are probably better designers, but it’s difficult to measure objectively. And it’s hard to tell that they’re doing something different because they’re just writing code like everyone else. Plus, it’s unlikely they’ll be as effective if you drop them into a brand new, unrelated domain: graphics to planning, for example. While it’s true that some programmers are better than others, I doubt it’s 10X, nor will it be a consistently large multiple.