In software, metrics are everywhere. Mountains of them and, if we listen carefully, we can gain insights into underlying patterns in the software.
Typically build systems, task managers, bug trackers and test reports are the major sources of metrics. However, one source of metrics that is frequently overlooked is the source code repository, or repo.
When people think about repo metrics they typically think about static code analysis metrics such as cyclometric complexity, class coupling and technical debt. There is another aspect however. The repo can tell us about who drives the most change in the codebase, which days are busiest, whose commits are most likely to cause errors and require the most testing. It can tell us about who the experts are in different areas and where there are areas where the expert is no longer in the team. All this by simply analysing the activity in the repo.
This begs the question: if the repo has such useful metrics, why do more teams not look at them?
The challenge is that source control systems are typically not built with this type of analysis in mind. Whilst some do generate some metrics they are typically limited in scope and restricted to a single repo. Whilst most repos do offer an extensive API, trying to write your own reporting solution is difficult; managing huge volumes of data, removing duplicates, merging contributor records and keeping everything up to date. When repos can be updated multiple times a day this can quickly become overwhelming.
We at DevMetrics decided to have a go at it, and in the process of overcoming these challenges we almost immediately started to uncover valuable insights into our own team and practices.
We’ll be sharing interesting patterns and metrics we uncover on this blog, so keep an eye out. In the meantime, make use of the free trial to see what insights your repo holds that are waiting to be uncovered.