Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>We have a number of metrics that are collected as programmers do work, such as:</p> <ul> <li>Number of SLOC changed / added</li> <li>Number of errors / bugs injected in various stages of the process (during peer review, post peer review, post release)</li> <li>Change requests fulfilled / rejected</li> <li>Formal documents (software version descriptions, design docs, etc.)</li> </ul> <p>All of these are tangibles which I find useful in presentations for management and software quality assurance. But I have never found them terribly useful in actual evaluations of people's performance - which is the point made by several of the links you listed. I've found that Joel's points <a href="http://www.joelonsoftware.com/news/20020715.html" rel="nofollow noreferrer">here</a> are valid - metrics never promote a good team atmosphere.</p> <p>Unfortunately, we all live in a world where metrics are required by others (management, quality assurance, outside contractors, etc.). I've found that a balancing act is required - providing those metrics, but also providing evidence of intangibles - intangible being what each programmer has accomplished that is not necessarily tracked. For example, I had a programmer who spent a large amount of time investigating legacy code that no one else wanted to touch. Even though his metrics were low for that period of time, that effort was invaluable.</p> <p>The only way I've found to include such things has been to push for the creation of an additional intangible category and give it equal weight with the other metrics. Usually this is sufficient to swing the balance for a particular programmer.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload