Do you believe metrics can accurately measure a developer's performance?

Formulating developer metrics is kind of like writing HR regulations defining sexual harassment; it certainly can be done, but you can’t phrase them in entirely in reductive terms.

E.G. compare:

“Employees should not stare at their colleagues in a demeaning way or in a way which makes them uncomfortable.”

With:

“Eye contact should not last more than 1.5 seconds, and after finishing a conversation, an employee may not continue to look at another employee for more than 2.5 seconds.”

The second sounds so very much more objective and measurable, but is unworkable in practice and in fact doesn’t actually rule out harassing looks—-any more than stipulating that a programmer crank out at least 100 lines of code an hour will rule out programmer slacking.

The trap is conflating “objective” and “measurable” with being expressed in a reductive language describing actions which can indeed be objectively measured, but which bear no essential or logical connection with the way programmers deliver value.

I once made a 10 minute hack which saved our company $50 million dollars. I’ve also worked 80 hours a week for 11 months on code which was ultimately just thrown away.

Most companies I have worked for have had an end-of-year rank-and-yank-style of programmer performance review process which soaked up MONTHS of management bandwidth. It’s certainly annoying and inconvenient, especially if you do need to tap your manager for a substantial amount of help during that time, but on the other hand, there is something reassuring in the thought that evaluating our performance is something which everyone realizes needs a lot of discussion, negotiation, and TIME to see what the longer term impact of our efforts are.

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.

At best metrics could be some hints. It's always possible to game metrics and in bad ways, like the Commissar of the famed Soviet Nail Factory:

https://skeptics.stackexchange.com/questions/22375/did-a-sov...

I saw this question on a tech manager community that I follow and would love to see your opinion as well