Collaborytics is an analytics and visualization application for source code management systems. It's aim is to assist software development teams, architects, consultants and project managers to visualize various metrics that apply to software development projects. Strictly speaking, the repository being visualized doesn't have to be a source code repository, but could be a repository for, say, book-writing authors too.
Collaborytics helps users gain any useful information about a team's
adherence to
good Source
Code Management (SCM) practices--such as small
and frequent checkins--and good Extreme
Programming
(XP) practices--such as pair rotations
and collective
code ownership--by analyzing the evolution of a codebase in a
repository over time.
The motivation is to visualize metrics that developers, technical leads
and consultants like myself will find useful for gaining insight into
their software development process. For example, a popular social
coding service, GitHub, has some
graphs to visualize "Code
Impact" (lines added + lines deleted for all non-merge commits
during a given timeframe) and commit
activity by day and hour.
The questions that the minimum feature set
answers are:
- How active is each contributor/developer?
- Are the contributors/developers making small and frequent changes or
otherwise? (More
info on XP best practice of small and frequent checkins.)
- What are the trends and outliers in file impact and files/checkin
over time?
- What is the contribution level (# of unique contributors) for
different time periods (or iterations)?
- How do the various metrics relate to each other (exploration of
multidimensional metrics)?
Some of the questions I would like to answer with the visualization in
the future are:
- What are the most/least active areas of the codebase?
- Is there a good dispersion of code ownership amongst the developers?
- Who has more experience in what parts of the codebase?
- What are the trends in line impact and lines/checkin? This provides a
lower level of granularity
In the future, I would also like to incorporate other metrics such as flog scores, toxicity
and cyclomatic
complexity, but at the moment
I'm more interested in spotting trends emerging from source control
activity. Needless to say, we should always take software metrics with
a grain of salt. I find them particularly useful in spotting trends and
outliers and not in arriving at black or white conclusions.
