5 Developer Metrics Every Software Manager Should Care About
Measuring a development team’s productivity is one of the most difficult challenges that software managers currently face. Many managers advocate a range of complex metrics to assess productivity, while others use no metrics at all.
In our experience, we’ve found the following five developer metrics are essential for all software managers:
- Lead Time
- Active Days
The good news? These developer metrics can be derived from version control data that’s in your GitHub/BitBucket/GitLab or other code repository. Metadata from these modern code repositories provides real-time insights into engineering work patterns and the health of your team.
1. Lead Time
Lead Time is the time period between the beginning of a project’s development and its delivery to the customer. Your development team’s lead time history will help you predict when an item will be ready with a high degree of accuracy.
This data is even useful if your development team doesn’t routinely provide estimates, since the predictions can be based on the lead times of similar projects. As an example, assume that 50 percent of similar feature request had a lead time of two weeks or less, and 90 percent of these projects had a lead time of one month or less. You could confidently provide a lead time of one month for the current project. [For more on Lead Time and Flow, see our post: Boosting Engineering Productivity by Managing the Development Pipeline]
2. Code Churn
Code Churn is the percentage of a developer’s own code representing an edit to their own recent work. It’s typically measured as lines of code (LOC) that were modified, added and deleted over a short period of time such as a few weeks. The primary purpose of measuring churn is to allow software managers and other project stakeholders to control the software development process, especially its quality. When churn starts to spike, this can be an indicator that something is off with the development process.
For example, imagine a situation where a developer receives a very opaque set of requirements, like “the app needs settings” — something that’s not uncommon when working with product stakeholders. When this disconnect turns into weeks worth of iteration on the same feature without a lot of forward progress, that will show up as code churn. Churn rate can also help to identify problems with individual developers. For example, a sudden increase in churn rate may indicate that a developer is experiencing difficulty in solving a particular problem or is repeatedly polishing a feature that’s ready for release. A high churn rate may also mean that a developer is under-engaged. Other causes of high churn include an indecisive product team that has the developer running in circles. For more, check out 6 causes of code churn and what to do about them.
Impact is a measure of the effect that code changes have on your project, and a way to consider the cognitive load they place on the developer who implemented them. Change sets that are more difficult to implement will therefore result in a higher impact score. The impact of a change set depends on a variety of factors such as the amount of code in the changes, the severity of those changes and the number of files that the changes affected.
For example, adding 100 new lines of code to 1 file, could have much less impact than a change with far fewer lines affected if it includes multiple insertions and deletions across multiple files.You could also compare the current impact values with the historical values to determine the effect of a recent change set.
4. Active Days
An Active Day is a day in which an engineer contributed code to the project, which includes specific tasks such as writing and reviewing code. Engineers are uniquely skilled at building and solving difficult conceptual problems, so contributing code is one of the most important things that an engineer can do. Non-engineering tasks such as planning, meetings, and chasing down specs are inevitable.In fact, most teams lose at least one day each week to these activities.
Calculating this type of data allows you to see the hidden costs of interruptions, like how an all-hands meeting in the middle of the week affects overall productivity. With Active days, you can protect your team’s attention and ensure process-overhead does not become a burden.
Efficiency is the percentage of an engineer’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. A high churn rate reduces it.
Different types of engineers will have different efficiency rates.A engineer that is trailblazing a new solution may try a lot of paths in the discovery phase, and a low efficiency rate may be expected. The most prolific engineers contribute lots of small commits, with a modest churn rate, resulting in a high efficiency rate. Understanding an engineer’s typical efficiency rate can help you understand their character and where they will fit in best.
That wraps up our take on essential developer metrics. We suggest focusing on these particular metrics because you can’t track everything, and not every measurement is a key metric.
What metrics do you track in your organization? We’d love to hear your opinion and the metrics you find most valuable. Contact us at firstname.lastname@example.org
Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.