Re: Measuring programmer quality

Beware that by introducing measures, people will optimize for the measure, not for the intended goal.

If you measure the number of lines of code removed per defect, people will remove lines.
If you penalize the number of lines added, people will not add lines of code.
If you penalize the average time to fix, people will quickly/immediately close bugs, either as "not a bug" or as "fixed", regardless of whether that's true.

The underlying question of whether what people do actually makes sense in the context given (removing lines of code likely reduces the code complexity and hence is "good") is not easily answered by these metrics, and such metrics will pull people into the direction of gaming the metrics.

Comment on Re: Measuring programmer quality

Replies are listed 'Best First'.
Re^2: Measuring programmer quality by halley (Prior) on Oct 25, 2007 at 13:36 UTC
I also note that most if not all of the proposed metrics measure quantity over quality. Personally speaking, I expect my programming output is extremely low for professional developers. I take a lot of time to think out code beforehand. I'm driven to produce code which feels like it presents ideal textbook craftsmanship. The solution should be elegant. The code should be internally consistent. Only the very highest tier should express anything like business logic or application-specific behavior. There shouldn't be any crufty special cases. Test cases on each module should be automated and thorough. It's a "Zero Defect" mentality. But by some people's measure (especially dividing any metric over time), this output really sucks. -- `[ e d @ h a l l e y . c c ]`	[reply]
Re^2: Measuring programmer quality by deorth (Scribe) on Oct 25, 2007 at 07:00 UTC
Yes, metrics can and usually are gamed. Lets assume for this exercise that my colleagues and I are acting in the best spirit of perlmonks, and wish for self knowledge and self improvement through honest self-assessment :) (which isn't too far from the truth actually)	[reply]


No such thing as a small change
	PerlMonks