The 'best' software productivity metric I've ever seen is one I created and tested on a large code base. It only measures coding, but it's better than the other

The 'best' software productivity metric I've ever seen is one I created and tested on a large code base. It only measures coding, but it's better than the other metrics for that. It is based on information theory and credits code removed equally to code added. In the end, I reported the results to the devs and then stopped doing it because there was too much opportunity for abuse by my superiors. Once they got wind of it, they wanted to know everyone's scores and I could see where it was heading. The metric: It was based on a very powerful (and slow) compression algorithm such that it could measure the change in code. Since it used compression, whitespace, boiler plate, etc had essentially no impact. It was carefully tested by comparing the results against human assessments. The only clear issue was that it did over-credit mass changes (renaming a root package in a java project which caused all files to be changed). This could probably have been handled by adjusting the scores. After looking at other metrics (bugs reported, comments on bug reports, code reviews completed, comments in code reviews, etc) it was clear that some people made _huge_ contributions through activities that were ignored by the algorithm, and some people who had great software productivity scores contributed little in these other activities. They were putting all their time into their own code. FWIW, In the same exercise, I came up with another good metric to identify problematic code (rather than problematic people). That metric used machine learning to find code that needed to be refactored. But that's a story for another time.