It's great that developer productivity is getting more research love, as it is not easy telling developer advocates for my solution that, you still have to tell

It's great that developer productivity is getting more research love, as it is not easy telling developer advocates for my solution that, you still have to tell management that they still need to work for meaningful insights. I think solutions like GitPrime (now Pluralsight Flow), GitHub Insights (formerly Gitalytics), Waydev, etc. really gives the impression that you can easily rollup metrics for management, to help them understand developer productivity, but the simple fact is, there are so many variables, as this article alludes to. Take the microsoft/vscode project, which is being developed at an incredible pace. If you look at the raw numbers like commits, files changed, churn, etc. with the "Velocity" metrics in the following: https://public-001.gitsense.com/insights/github/repos?r=github%3Amicrosoft%2Fvscode&v=repo https://public-001.gitsense.com/insights/github/repos?r=gith... you can see that it swings quite wildly at one point of time. And if you only look at typescript file changes in the following: https://public-001.gitsense.com/insights/github/repos?q=langs%3Atypescript&r=github%3Amicrosoft%2Fvscode&v=repo https://public-001.gitsense.com/insights/github/repos?q=lang... you can see the patterns are much more consistent. Based on these wild swings, I really don't know how GitPrime and similar solutions are not generating metrics with big banners that says "these numbers may not be very useful". In the business world, business intelligence is widely accepted and management fully understands that you still have to work at it, to get meaningful insights from BI and I'm hoping this attitude is adopted for developer insights. I'm still early in my research, but I believe the metrics that both management and developers can get behind are impact based metrics. Impact really can't tell you if somebody is more productive than another person, it just says they are having a greater impact to the code base. For example, with impact analysis, you can quickly identify busfactor that can tell management, if this developer leaves, we are probably going to experience delays in development. Impact analysis will also make it easier for developers to fight for raises as they will be better able to tell leaders how they are having an impact, compared to say a colleague. Impact analysis will also tell you if a developer is not stepping out of their comfort zone or confirm that you are not giving them a chance to expand, and so forth. I personally think, trying to optimize developers for speed is a loss cause, and we should be focusing on metrics that can help reduce project risk, which I think everybody can get behind.