in reply to Measuring programmer quality

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

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.

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 ]

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)