4 ms·
Disclaimer: I'm the founder of GitSense which is working to make software metrics a good thing for both leaders and developers, so assume I have a bias. > line
by sdesol 5y ago
Disclaimer: I'm the founder of GitSense which is working to make software metrics a good thing for both leaders and developers, so assume I have a bias.
> lines of code/number of commits/number of changelog items != productivity
This is the biggest challenge that I'm currently faced with right now, as GitPrime (now Pluralsight Flow), GitHub Insights (formerly Gitalytics), Waydev and others have been very effective at giving the impression that you can easily roll-up metrics to quantify developer productivity. You will be surprised by how many times people want a simple score or a simple graph to summarize how productive a developer is.
What really bugs me about lines of code/number of commits/etc. metrics is they are actually really useful for developers, but because they are used incorrectly, it takes a lot of effort to explain to people that context matters. For example, if I want to know what developers contributed to the src/vs/base directory in the vscode project in the last 30 days, lines of code/number of commits/etc. is quite useful. See the following for an example of what I mean:
https://public-001.gitsense.com/insights/github/repos?q=path%3Asrc%2Fvs%2Fbase%2F*%2Bwindow%3A30&r=github%3Amicrosoft%2Fvscode&v=repo https://public-001.gitsense.com/insights/github/repos?q=path...
If you switch to the impact view, you can quickly tell based on code churn, commits and other metrics who had the greatest impact. I talk a bit more about impact in the following post, so I won't repeat things here:
https://news.ycombinator.com/item?id=26457072 https://news.ycombinator.com/item?id=26457072
Right now what I'm working on is making a connected efforts graph that should help management better understand how much effort it takes to develop code, which I'm hoping will displace the notion that you can quantify productivity with low hanging code metrics. For example, when you look at a code change, you should be able to see that it is connected to x number of meetings, x number of emails, x number of code review comments, and so forth.
When it is all over, tracking every line change is a good thing as it benefits everybody, but how it is used today out of convenience is certainly presenting challenges for what I'm working on.
Edit: Do not install my tool as the docker image has an out of date license that I need to update.
- hu3 5y agoIt's funny because this week I'm at -2000 lines of code after refactoring, removing redundant slow tests code and implementing some small new features. Guess I'm fired.
- sdesol 5y agoNot if the metrics is done right! Code churn is always positive since it's "lines added + changed + deleted" Honestly your example is exactly why software metrics is a good thing for developers. If you run blame across the file, it won't be obvious that you deleted a bunch of code, but code churn history will.