In response to "No Silver Programmers," Reuben Fries points out:

Say I'm a pretty good developer and there's this guy who is 5x worse than me, meaning it takes him a full work week to finish what i will finish in a day.

but then, what happens when it has 3x as many bugs, and it takes him 5x the time to fix each one?   suddenly we're at 15x for the bug fixing phase.  and actually, it should take him more than 5x as long to fix each one -- fixing bugs is much harder the more there are in the same code, and harder the longer it the time between writing them and finding them.  (and think about how much more time occurs between writing a bug and fixing one for this guy compared to me -- he has 3x as many bugs, often blocking other bugs from being found and always blocking other bugs from being fixed, and he takes 5x as long to fix each one...)

and it doesn't scale linearly when we look at code that will take me a month.  that's going to take him more than 5 months.  his design mistakes will pile up and his buggy code will pile up.  something that takes me a year he may simply be incapable of doing.

Yes. Further, a team with him on it will require more coordination than one made of average-or-better developers. A 90% finished system will suddenly reveal a crucial weakness because of his work violating encapsulation or somesuch.

Bad programmers are not good programmers who are slow. They are actively counter-productive to the team.

This is another great point why, to improve your team's productivity, it's important to focus not on the hope that you can discover a magical super-programmer but on rooting out incompetence.