He's not talking about either an ordinary programmer or a cracker but the Mythical Genius Hacker(tm): Yes, I am serious; a hacker on a roll may be able to produce, in a period of a few months, something that a small development group (say, 7-8 people) would have a hard time getting together over a year. Whether claims of programmer productivity variation are true or not, I'm dubious that the most productive programmer necessarily goes by the title "Hacker" or necessarily operates in the "mad genius" fashion.
As a software engineer, I'd encourage managers to avoid the "hacker" who is more productive because only he understands the poorly designed system he created. The genius hacker myth is counter-productive here.
We had a "Genius Hacker(tm)" where I currently work. He got projects done quick and they stayed working for a long time. He left and we needed to extend some projects or something would break on another. Everyone agreed, it was some of the most horrible code any of us had ever seen. Also, over-engineering is an understatement. He still plagues us years later as we find his legacy floating around.
I think sometime poor design or horrible code is quite subjective. For example, when I write complex query for performance critical system, and no other colleagues understand, is that my fault?
I'm talking about metaclasses in Python for the hell of it. I'm talking one-liners that consist of map, lambda, map, lambda, filter, map, map, map, join. I'm talking about inconsistent indenting and one letter variable names everywhere. I'm talking about huge monolithic code bases, all of which he wrote, containing code copy and pasted from each other instead of making a library. I could go on but I'll spare you. I agree that "poor design" and "horrible code" is quite subjective but sometimes it's an easier call than others.
Not if you wrote clear supporting documentation appropriate for an audience that will not be familiar with your particular conceptualization. This in itself is a real art.
As a software engineer, I'd encourage managers to avoid the "hacker" who is more productive because only he understands the poorly designed system he created. The genius hacker myth is counter-productive here.