[ ... ]
So I think that though the 100x figure is a bit extreme I do believe
there can be significant differences between developers, especially when
you don't assume we're talking about some super-shop that only hires the
best and can afford to do so...and take the time to interview and
replace people when they don't pan out as expected.
In _The Mythical Man-Month_, Brooks quotes a study by Sackman,
Erikson, and Grant, giving a factor of approximately 10x in terms of
productivity, and 5x in terms of program speed and space.
That study, however, was conducted in 1968, and (a point that's often
ignored) was originally written as a comparison of online to offline
programming. That points (at least to some degree) to the difficulty
of extrapolating from that study to much that's meaningful about
current practice. For the sake of argument, however, let's assume
that it gives a rough idea of the expected range of "native ability"
of programmer.
I do think a couple of factors are worth considering, however. First
of all, in 1968 there were relatively few programmers, and I'd guess
that most had formal background in engineering, mathematic, or both.
In 1968, there was virtually no such thing as a college with a major
in computer science, but today there are quite a few. Unfortunately,
for every good one today, there's at least one more that'll give a
diploma to anybody with money.
That's likely to lead to a larger range of variation in both
directions: there are almost certainly more people who picked
programming as a job simply because it pays well and such (even
though they may well lack any aptitude for the job at all). On the
other side, there's a whole lot that can be accomplished by applying
known, proven principles today that hadn't been invented at all in
1968. The average has probably stated about the same, but the best
certainly have a great deal more education now, while the worst
probably have less.
Second, there are a lot more specialized tools reasonably easily
available today than in 1968. Some maintain a high level of awareness
of those tools, and are likely to apply them (to at least some
degree) when they're at least reasonably appropriate. Others barely
know a single language, and have no idea when another tool would be
more appropriate.
Either of these could probably lead to a 2x factor by itself, so
multiplying the three together, we've accounted for a 40x factor --
but this would still be between the best and the worst, NOT between
the best and the average.
Assuming relatively minimal skew and such, that gives a difference
between the top and the average of ~6.3x (no, not 20x -- the factors
multiply, so it's sqrt(40), not 40/2).
While there are certainly other factors I haven't tried to take into
account, I think those are probably the biggest ones. A 10x
difference between the top and the average might be believable, but
100x strikes me as more than just a bit extreme -- it sounds
downright unbelievable.
I'd also note that there's at least one factor working in the
opposite direction: we routinely expect systems today to be both
larger and more reliable than any but a tiny percentage were in the
1960's. In a large, high-reliability system, it's MUCH more difficult
for even the best coder to be drastically better than an average one.
In a large system, processes and procedures take up a larger
percentage of overall time -- and in the process the time taken for
the coding itself takes up a smaller percentage.
Assume programmer A could find and fix a particular bug in 6 minutes,
but programmer B would take a full hour to do the same thing. So far
A is 10x more productive. Now we have a code review where we have
(say) 10 people look over the code. First we have 10 minutes where
people discuss the weather, wait for the people who are inevitably a
few minutes late, etc. Then the programmer spends 20 minutes
outlining the bug and the change -- and since the meeting involves
about the same level of people (overall) either way, A can't explain
it a whole lot faster than B could.
Then the code is reviewed -- again, since about the same people are
involved either way, the review takes about the same time either way.
To give him the benefit of the doubt, let's assume A figured out a
much simpler way of fixing the bug, so for A's fix, the meeting
(overall) runs 45 minutes, but for B's fix, it runs an hour and a
half.
In overall productivity, A's change took .1 + .75*10 = 7.6 man hours.
B's change took 1 + 1.5*10 = 16 man hours. The 10x factor for the
original change is now just over 2x -- and in all honesty, even
that's probably being generous.
This also explains why you want formal reviews to involve fewer
people if possible -- in the example above, if the review team was 5
people instead of 10, the numbers would work out to 3.85 and 8.5 man-
hours respectively. The overall difference is still well under 3:1
though...
P.S. If you really object to "man-hours" please feel free to read
those as "person-hours". Personally, I find "person-hours" much
clumsier to say -- and the percentage of programmers I've worked with
who were female was tiny anyway.
This