There's something wrong with this whole line of thinking. Perhaps its the measuring of productivity by loc, or pages of documentation written (shudder). Or maybe its the strong negative tone of the whole document.
Maybe it's me, but if a manager can't figure out the good and the bad performers in the group and figure out how to get the most of the resources available, then perhaps the most useful change would be at the management level.
Get to know your people. Look at their code, talk to them about ideas. Are they producing? Is there resentment among the group?
Please don't measure productivity by loc/day or worse yet pages of documentation. Short and sweet can be much more productive than overly verbose and redundant.
From what I've heard and read, it tends to have more to do with the manager either not working closely with the individuals and/or not understanding what they are doing. This is especially common when it's a non-developer managing the group.
The best measure of productivity is the amount of functionality added and the number of bugs produced. Secondary metrics would be the same two numbers for when someone else makes the changes. Of course, the real trick is in accurately gauging the difficulty of the tasks.
I am really suspicious of these 100:1 metrics because I don't think they're across the board. That is - they apply to different people at different times. Let me give you an example. One thing I do at work is crunch numbers and make predictions. I do this a lot, and I can grab data from all over the place, parse it or munge it, fit curves, draw graphs, show how two or more datasets are correlated, package all this into a nice report, schedule it to run regularly or generate the report in response to some event, blah blah. Sometimes I can turn around requests in just a few minutes because I have a ton of Python I've already written, I know where to find all the data, and so on. Another equally talented person could take a week or two to do some of this stuff, if they started from scratch and didn't have my mathematical background. And there's stuff they can do that I'd be so much slower at. For any given task, 100:1 differences in performance between team members is normal. Over time, tho', over a range of tasks, I doubt there's even a 5:1 difference within most teams, maybe not even 2:1.
Maybe it's me, but if a manager can't figure out the good and the bad performers in the group and figure out how to get the most of the resources available, then perhaps the most useful change would be at the management level.
Get to know your people. Look at their code, talk to them about ideas. Are they producing? Is there resentment among the group?
Please don't measure productivity by loc/day or worse yet pages of documentation. Short and sweet can be much more productive than overly verbose and redundant.