Look beyond code churn to minimize technical debt

How do you measure developer productivity?

This question has troubled developers, team leads, managers, and C-Level executives for decades. Folks have tried everything from counting code to measuring product success, and from analyzing time spent to even using the Fibonacci sequence to forecast project size.

In recent years, the popular claim is that code churn is the best metric to pay attention to. At GitClear, we believe these metrics aren’t an ideal way to measure developer productivity. So, you might be asking: if those metrics are flawed, then what should we be measuring? Good question. Let's explore deeper.

The flaws of measuring code churn

Code churn is typically defined as the percentage of a developer’s own code representing an edit to their own recent work. According to GitPrime, the main reason to measure 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.”

However, GitClear founder Bill Harding says that this line of thinking is inherently flawed. “Churn only exists relative to a developer's commit habits. That is, if Alice makes one commit per day, she will appear to have low churn since all of her work was lumped together. If Bob makes 10 commits that end up accomplishing the exact same work, he’s going to appear to have a problem with churn. Our belief is that the work style of Bob and Alice are both fine; what matters is just how much they're getting done. That's what Line Impact measures.”

So, what exactly is Line Impact?

Line Impact is a relative measure of commit value. We take into consideration the typical performance of developers as individual contributors, as well as your dev team as a whole. We look at changes like additions, updates, and removals, and look at their relative impact together to quantify how meaningful the entire commit was. Here's a handy chart that details the exact metrics we look at:

Technical debt: less scary than it sounds

GitPrime measures technical debt in a way that encourages coders to be more cautious before they make a commit. If they have to revise it later, that counts against them negatively. But assuming that Alice is ending up doing the same amount of work as Bob, there's no reason we should be trying to change the work style of either one. Whether Alice takes 3 hours to perfect one commit or Bob takes 3 hours to commit and revise three times, the work evens out.

The concept that all code must be done perfectly the first time around can be harmful to overall productivity and team morale. Forcing all developers to code, in the same way, isn’t the best way to manage your team. As the saying goes, “If you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.” Measuring a developer’s performance relative to themselves will give you better insight into what their coding style is, where their strengths lie, and how you can best manage them.

Whether you can count your teammates on one hand, or you are managing a dev team that’s spread across multiple time zones, evaluating code effectively is imperative to the overall success of your organization.

Ready to learn more?

Grace Bradford

Visual Designer at GitClear

Grace is a content creator who's passionate about brand aesthetics, cross-team collaboration, and crispy french fries. She's currently working on her most daunting project yet: a definitive ranking of all chicken tenders in Seattle.