In email, Charles Gallo makes a point regarding "No Silver Programmers":
I think the HUGE difference between the mean programmer, and the silver bullet programmer is NOT how fast they can code "x" function points. The HUGE difference is when they sit down to solve a problem, and they can come up with an "elegant" solution to the problem that takes 1/2 the number of function points (or less), and therefore even the average programmer writing the design that these super programmers came up with would do it in 1/2 the time and with 1/2 the bugs (because there is 1/2 as much code).
This is definitely a fair point -- good programmers sometimes hit home runs. I had a case in point last year, when I had a client that had a problematic partner. The partner had a solution that they believed to involve such a huge barrier to entry that they could charge whatever they want, not respond to user needs, etc. Well, sadly for the partner, the barrier to entry was "write a parser."
Parsers are hard if you don't know what you're doing. Given their adamant refusal to make requested changes (not "that will take time" or "that will take money" but "no, that cannot be done") and confidence in their position, I strongly suspect that their parsing code was a very big, very complex hairball of hand-crafted code. On the other hand, I had Antlr, the Visitor pattern, and a couple weeks.
But the question is not "do homeruns exist?" but "To what extent is overall productivity affected by homeruns?"
This is a hard question to answer. On the one hand, you can say "Homeruns are infrequent -- even the best programmers spend a lot of their time doing mundane work." On the other hand, you can say "Homeruns, though infrequent, have ongoing effects on the system. Implementing a new Visitor over a nice AST is easy, if not entirely trivial." And, sometimes, a homerun can be something like Google's PageRank and have consequences vastly greater than "who has above-average productivity?"
I'm going to try to wiggle out of the conundrum by saying that homeruns (or even "extra-base hits") more often come from design and architectural decisions than from actual coding techniques. Not always, but more often. And once you raise the question of the distribution or impact of architectural talent, I don't think we have any data. And since we don't have any data about it, I think it's very hard to reason about it. I have my biases (I strongly distrust architects who don't code) but I respect the opposite belief (architects are less effective if they are busy "in the weeds").