Developer activity metrics Part 1: Gitinspector
Measuring developer productivity is one topic destined to be a cause of heated discussions. Leaving all sentiments aside, here’s a short list of tools with ambition to provide analytical analysis to the developer activity.
- Gitinspector – free and down-to-earth statistical tool for Git repositories
- Hello2morrow – builds code dependencies graphs and identifies software architecture rules violations
- Semmle – a commercial tool with main focus on ability to view results of static code analysis under different angles
- BlueOptima -Developer Efficiency Analyzer – a commercial tool that based on the company’s algorithm is able to translate number of committed lines into hours of developer effort
What we can measure with Gitinspector:
1. The size of a pull request
Historical commit information by author actually has an
interesting twist:
(insertions + deletions) / number of commits
= the size of each commit
This is an objective indicator of cries of pain you might’ve let escape your chest while facing overwhelming pull requests.
2. Efficiency of the change
Number of rows from each author that have survived and are still intact in the current revision Generate the report for a time frame of a sprint or a release development cycle, and the tool will display a number of survived lines for each author. So, if during the sprint, you add or modify 100 lines, but only 10 of them survive at the end of the sprint, it’s time to focus on quality and pertinence of
your work.
your work.
3. Cadence of the change
Ignore most of the History timeline info and focus on Modified Rows for each month:
Modified Rows / Total Code Base Rows = % of monthly change % of monthly change * Coefficient of the ave test time = estimated time you need to test your changes
Yes, this is the approximate metric, but given a few months on the project, you’ll be able to determine the coefficient and hence estimate the testing time
4. Areas of expertise
Is mostly responsible for section can be easily called Authors’ areas of expertise – we always tend to spend more time coding what we like to code, or we end up becoming experts in what we have to code. So, file extensions indicate language preferences, and file locations show level of comfort with the code base – after all, making a change to the framework core carries more responsibility than implementing a new handler or a view.
great nice post , very helpful Judi Bola
Great to see BlueOptima mentioned, but this sounds like its Coding Effort metric is based on number of lines of code. In contrast to such a metric, it provides a true measure of developer effort, based on 36 static metrics, benchmarked in terms of its Volume, Complexity, and Interrelatedness. More here: bit.ly/NbDBOCE