Gitential Data Explained
measure & analyze
Main Performance KPIs
Estimated time spent by author on writing the inlier lines by a median speed derived from his overall commits (median of his speeds for all commits). Scale has been set to min 5 minutes and maximum 4 hours per commit with the assumption of frequent and regular code commits.
Number of individual developers (contributors) contributed to the work in the selected repositories within the given timeframe. It can be any kind of commit activity or comments.
Efficiency is the percentage of a developer’s contributed code that’s productive, which generally involves balancing coding output against the code’s longevity. Efficiency is independent of the amount of code written. The higher the efficiency rate, the longer that code is providing business value.
Source lines of code, also known as lines of code, is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program's source code. Calculation: total lines of code inserted – total lines of code deleted.
The amount of commits done by a developer. This represents the number of changes made to the original code which can be extensions, rewrites, optimization, bug fixes, etc.
Velocity gives us an estimation of on average how many lines of code is written in an hour. It is the ratio of total productive code volume to total estimated coding hours. Unexpected spikes in velocity can mean engineering difficulties in implementation which might require support from other team members or from management.
Gitential is a platform that delivers automated software development analytics to help teams measure, analyze, and improve development productivity based on actionable insights.
measure & analyze
Top Deep Dive
Ratio of elapsed time to utilized time based one estimated working hours. Elapsed time considers a 5-day working week and an 8-hour working day in its calculation. Holidays are not considered.
Unproductive Code (Churn)
A quantified representation of the event when an engineer rewrites their own code shortly after it has been checked in - less than 3 weeks old. A certain amount of Churn code can be expected for any developer.
Total number of lines of codes which are not marked as test line.
Total lines of code that hasn't been rewritten in the last 3 weeks. As we are taking into consideration a 21-day window for this metrics the most accurate information will be available after 3 weeks. As today’s productive code can turn to unproductive within the next 21 days, it’s best to analyze it for older implementation.
It is important because simple code is easier to maintain and easier for other engineers to work in. More experienced engineers tend to write simpler code. Lower code complexity is better.
Total number of lines of code which are marked as a test line.