4 ms·
Metrics can only measure one or more aspects of performance, assuming they are well crafted. And, metrics rarely cover all aspects of work that is being done. T
by kelthan 3y ago
Metrics can only measure one or more aspects of performance, assuming they are well crafted. And, metrics rarely cover all aspects of work that is being done. Take a few abstract metrics for example:
* X SLOC written / unit time
* X Bugs resolved / unit time
* PRs turned around in X unit time
Those represent a significant portion of the work that developers do: writing, debugging, and reviewing code. However, targets for these metrics are going to vary depending on experience of the developer and a number of other factors that may be out of the developer's control. Further, several of these metrics are in conflict with each other:
* A developer can't write lots of code if you are fixing bugs -- bug fixes often result in very few, or even no lines of new code being written.
* Big or complex PRs will take longer to review than short/simple PRs.
* Fixing bugs (reading code) takes significantly longer than writing code.
* Refactoring code for simplicity, supportability, or clarity takes significant time and may result in little to no new SLOCs--but it can be highly valued work.
* Not all bugs that affect a codebase are the result of problems in that codebase. It could be that some dependency changed requirements or is providing data in a way that "shouldn't happen" according to the design requirements.
* Time spent boosting one metric is opportunity lost to boost another one--unless your developers are significantly under capacity.
* A developer can sling lots of new code without adding significant business value which looks good on the metric, but is bad for business.
Hopefully that shows how metrics can be misleading. Metrics are like rulers: they are good at measuring things, but they can't always tell if what you are measuring is the right thing. You will still need to have subjective evaluation in addition to the metrics to properly evaluate a developer's overall contribution to the team.