|
The truth is that the difference is even more extreme. Good programmers are much more than 100 times more productive than average programmers. Good programmers create features, designs, and implementations which are more elegant, cleaner, more understandable, more robust, less buggy, and much more valuable to the end user. Consider J. Average Coder. He implements a feature in a typically half-assed way. The feature isn't well thought out, it barely works from a user perspective and has horrible usability. Anyone who doesn't think this is how average coders work has never experienced software developed by average coders. More than that, it's buggy and hacky and it serves as a development time sink, a tar trap for the entire development team. Bugs get reported and because of how messy and convoluted and fragile the code is it takes a lot longer to fix each bug. And in the end the effective productivity of that coder ends up being astoundingly low. Because the end result is a single feature that has taken a tremendous amount of coding and especially bug fixing on his part and on the part of his co-workers. The ratio of total end-user value to total invested dev-hours is incredibly low. Now compare this with Dudley Code-right. He comes up with not only an excellent feature with high-user impact but he also comes up with a very elegant way to implement it. Boom, it's done, and nearly bug free. What bugs are found are quick to fix because the code is so clean and well put together. The ratio of total end-user value to total invested dev-hours is through the roof in comparison. Not just a factor of 100 different, but factors of thousands different. There are tons of easy examples out there in the real world. Look at open source projects with tiny dev. teams, like nginx or varnish, and the value of those code bases relative to the effort behind them, then compare that to some random line of business software abomination from the enterprise trenches that has had hundreds of thousands of dev-hours dumped into it. |
It's not the same thing as what we call "evidence", which consists of actually going out in the world and collecting information from more than a tiny and highly biased sample (which, like it or not, is a fair description of the set of programmers most of us will run into over the course of a career).
For instance, for one "Dudley Code-right" who is just as you describe, how many "Dudley Code-fast" exist, who are just as you describe except that no one else can understand their elegant constructions and it turns out that the "nearly bug-free" part, well... disappoints? Dudley Code-fasts look highly "productive" for a little while, then cause big problems down the road.
What we're dealing with here is the representativeness heuristic, which often makes us misjudge statistical truths. It's akin to the way people are much more afraid of flying than of driving, even though the former is orders of magnitude safer.