In software development, accurately measuring the effort invested in a task is essential for optimizing team efficiency.
One effective approach is to estimate the start of Coding Time based on the date of the first PR commit and an approximation of how long it might have taken to write that code. This way, the start of Coding Time more accurately reflects when the developer began working on the task.
How Does Teambit Adjust Coding Time?
Here’s a brief explanation of how Teambit leverages historical data to make this estimation. The process is divided into two main stages:
1. Estimating Code Writing Speed
The first step is to analyze the developer’s recent activity by evaluating the number of lines of code added and the time intervals between consecutive commits. To ensure data relevance, excessively large or small commits, as well as those with long periods of inactivity between them, are excluded. This results in a filtered subset of commits that better represents the developer’s work under normal conditions.
Using this filtered data, key statistics such as the average, median, and percentiles are calculated, removing outliers that might skew the results. The writing speed is defined using the 75th percentile (p75), representing a high but consistent performance level.
2. Adjusting the Start of Coding Time
With the estimated writing speed, Teambit adjusts the start of the coding time in a PR. Using the first relevant commit (excluding merge commits) as a reference, if this commit contains fewer than 1,000 lines of code, the time required to write that code is calculated based on the previously determined writing speed. This estimated time is then subtracted from the date and time of the first commit, providing a more accurate approximation of when the developer started writing the code.
This approach enables a more precise measurement of development effort, especially when the exact start of the work cannot be determined directly from the associated task. By adjusting the time of the first commit according to the developer’s writing speed, a more realistic representation of the time spent on the PR is achieved, aiding in productivity analysis and future estimations.
Considerations Regarding Developer Speed
While a developer’s code writing speed is a useful metric for adjustments like the first commit’s time, it should not be interpreted as an absolute indicator of productivity or quality. Writing code is just one part of the development process, which also includes activities such as design, research, testing, and reviews. Evaluating a developer solely by their speed can lead to incorrect conclusions, as software development is a complex and collaborative process.
Conclusion
This approach provides a more precise way to measure development effort, especially when the start of the work cannot be directly determined from the associated task. By adjusting the time of the first commit based on writing speed, a more realistic representation of the time spent on PR development is achieved. This proves valuable for productivity analysis and future estimations.