SADeveloper has an interesting article on programmer productivity,
basically along the lines that a good programmer can be 5-20 times as
productive as a poor one. My first boss drilled into me that “software
development was one of the few professions where a one person can be
ten times as productive as another.” And I believe it — poor
programmers can screw up code, get stuck constantly, miss requirements
and have to re-work things, deliver bug-ridden code, etc. Other
“creative” professions (science, music, etc.) are similar in that the
productivity gap can be surprising.

Ray from CodeBetter had some interesting counterpoints
to the article, but I’ve seen firsthand how much poor developers can
stink. If you remove all thinking from the task, then the only
measurement you’d need was typing speed & mouse-hand speed. But
that’s not what defines the productivity of a developer — it’s what
their brain does that makes the difference.

Now, the funny part is I think with proper training, a good architect,
smart division of labor, & in-place processes, you can narrow the
productivity gap. Someone who sucks should be moved or fired. And in a
gunslinger code culture, your rock stars will always smoke the average
Joes. But what if you instead have

• training so that everyone knows the project process
• an
  actual project process that minimizes problems of scope creep,
  requirements confusion, and implementation/architecture snafus. RUP
  comes to mind, but there are others (MSF, XP, etc.).
• dedicated people for the tasks that “poor/average” programmers
  often mess up on (architecture, project planning, requirements, etc.)
• a software architect who can divide tasks among developers according to their skill level
• a culture that encourages learning and asking questions
• a good screening system to get rid of or avoid hiring people who don’t work well in teams
• a mentoring system to pass along tips and information

With the above, I think you can reduce the productivity gap. You
eliminate or reduce many of the issues that cause weaker developers to
fall so far behind their counterparts. You’ll still have faster and
slower programmers, people who can devise algorithms or who know their
APIs and patterns backwards and forwards instead of having to Google
them all the time. But time and again, some of the biggest sandtraps
I’ve seen programmers fall into are ones related to architecture,
project management, and failure to follow a methodology and process
that guides people towards better applications.