Agile, Continuous Delivery

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.

  1. Gitinspector – free and down-to-earth statistical tool for Git repositories
  2. Hello2morrow – builds code dependencies graphs and identifies software architecture rules violations
  3. Semmle – a commercial tool with main focus on ability to view results of static code analysis under different angles
  4. 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.

Screen Shot 2016-05-08 at 2.21.14 PM

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.
Screen Shot 2016-05-08 at 3.06.28 PM

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

Screen Shot 2016-05-08 at 3.06.28 PM

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.

Screen Shot 2016-05-08 at 3.24.03 PM