Development time tracking for Git repositories
gitential.com
Development time tracking for Git repositories
1–6 of 6 posts
Re: Development time tracking for Git repositories
#2This is LOC as BS performance metrics again. Days can go into a one line change, while klocs can be auto generated in seconds. The (un)productive lines are pretty bad as well - there are good reasons to stub out, or delay properly implementing some things until next commit/day/week. I really hope it doesn't get popular and no non-technical manager find it.
Re: Development time tracking for Git repositories
#3This is LOC as BS performance metrics again. Days can go into a one line change, while klocs can be auto generated in seconds. The (un)productive lines are pretty bad as well - there are good reasons to stub out, or delay properly implementing some things until next commit/day/week. I really hope it doesn't get popular and no non-technical manager find it.
Dropping loc requires an accurate token based diff, which requires fast language parsers. While there are such projects, non of them are widely adapted - in contrary with the notorious loc.
BTW would You prefer a magical deep learning solution which tells a grade about your code quality - also hiding most aspects of the analysis?
Re: Development time tracking for Git repositories
#4This is LOC as BS performance metrics again. Days can go into a one line change, while klocs can be auto generated in seconds. The (un)productive lines are pretty bad as well - there are good reasons to stub out, or delay properly implementing some things until next commit/day/week. I really hope it doesn't get popular and no non-technical manager find it.
It doesn't say if you write lot's of code it is good. Moreover probably that is not good. Instead you can measure proportions for example. (unproductive / inserted)
You can draw the conclusion because you are the one who know your code.
Re: Development time tracking for Git repositories
#5This is LOC as BS performance metrics again. Days can go into a one line change, while klocs can be auto generated in seconds. The (un)productive lines are pretty bad as well - there are good reasons to stub out, or delay properly implementing some things until next commit/day/week. I really hope it doesn't get popular and no non-technical manager find it.
It doesn't say if you write lot's of code it is good. Moreover probably that is not good. Instead you can measure proportions for example. (unproductive / inserted) You can draw the conclusion because you are the one who know your code.
The fact that it assigns the judgment of what code is productive and what isn't is already problematic. It's not something you can detect automatically. Lines replaced in the next commit can be very productive.
The project also judges the volume of code. Even the alert says: " Developer Mark: 23 days elapsed without commits." Honestly: if you didn't know that without this tool, you've got problems at manager level. And if you knew there's no new commits, you don't need this to be an alert.
Re: Development time tracking for Git repositories
#6This is LOC as BS performance metrics again. Days can go into a one line change, while klocs can be auto generated in seconds. The (un)productive lines are pretty bad as well - there are good reasons to stub out, or delay properly implementing some things until next commit/day/week. I really hope it doesn't get popular and no non-technical manager find it.
Dropping loc requires an accurate token based diff, which requires fast language parsers. While there are such projects, non of them are widely adapted - in contrary with the notorious loc. BTW would You prefer a magical deep learning solution which tells a grade about your code quality - also hiding most aspects of the analysis?
Requires token based diffs for what? I think the whole idea of a graph that puts automated code measurement against a dev name is misguided. It's very noisy and any actionable information you may want to get from it should be clear from other sources. Code is there, because that's the tool used. Who wrote how much code on what day is non-actionable.
If you can grade code quality, do it pre-commit/pre-merge. Why allow bad code in the first place?