Interesting!

I first latched on to this problem when I was working over at IBM Greenock in 1996. There were one or two really lousy developers working as contractors. They were "debugger jockies". While the rest of us went home early, they would be in until 9pm every night debugging the crap they had coded earlier in the day. What irked me most is that they got paid for all those hours. Guys building utter crap and then fixing it with endless hours on the debugger were earning at least 50% more than me.

This focused my mind on two things - the manager had no visibility on this - and the hours spent on the debugger is an antipattern.

Hence, as a manager I now use time spent on the debugger as a "smell" which tells me to go investigate whether the developer is any good or not. I also invented metrics which encourage good quality development with greater speed. I ask developers to focus on development and test lead time - time to process working code from a requirement to complete and passed out of test. This means that code-fix guys who use a debugger as a first line of attack will not produce the numbers, whilst quality first through good analysis and design, with reviews and unit tests will always outperform the hacker.

When a manager only measures input - i.e. hours worked or effort - then development degenerates down to "who is the best debugger jockey".

David -- David J. Anderson http://www.agilemanagement.net Author of "Agile Management for Software Engineering"