Should we measure developer productivity?

About 10 years ago, I wrote a blog post called “Can we measure developer productivity?” In it, I discussed the many objective attempts that had been made to do it — lines of code, function points, etc. I also proposed some subjective measures. Still, the conclusion was that despite the desires of KPI-loving managers, there was no viable way to measure the productivity of an individual software developer.

I mention this article published 10 years ago because things have changed significantly in the years since. When I wrote it, Git and Mercurial were both prominent and popular software source control systems. I was a software manager at the time, migrating my team off of Visual Source Safe from Microsoft, and we decided to go with Mercurial because it was much more Windows-friendly.

We picked the wrong horse because, in the years to come, Git would become the de facto standard for version control. As a result, a cottage industry has arisen around Git repositories. GitHub is a huge business for which Microsoft paid $7.5 billion. Many companies now provide metrics around your code in Git. And many of those companies purport to measure the productivity of software developers.

Gimme metrics

If we concede that it is possible to measure developer productivity (a proposition that I am not completely sold on), we then must ask whether we should do that.

The desire to do so is certainly strong. Managers want to know who their best developers are, and they want metrics that will help them at performance evaluation time. HR wants to be able to document performance issues. CEOs want to know that the money they are spending is being used effectively.

Even if you use new tools to measure individual developer productivity, those metrics will likely be gamed. Lines of code is considered a joke metric these days. “You want lines of code? I’ll give you lines of code!” Is number of commits per day or average time to first PR comment any different? If you measure individual developers on these metrics, they will most definitely improve them. But at what cost? Likely at the cost of team productivity.

An old CEO of mine used to say that software development is a team sport. If individual developers are measured against each other on any metric, they will start competing with each other, especially if money and promotions are on the line. And a group of people competing against each other is not a team.

It is teams, not individual developers, that get things done in the software business. Software development is interesting in that regard. The actual coding is often best done by individuals in deep thought, but the work that happens before and after the code gets written contributes greatly toward making things successful.

Measure the team

A development team discusses the design and implementation of a given project before any code is written. When the individual developers write the code, it is often with the help of teammates who answer questions and provide insight. All team members review and approve what is done during code reviews. Everyone works together to make things happen.

The strength of the team is each individual member. The strength of each member is the team. —Phil Jackson, NBA coach

That is why, instead of measuring individual developer productivity, it is team productivity that should be measured. Developers working together as a team, pushing toward a common goal, is what managers truly want.

Teams know that if they improve their team metrics, they improve their success. Teams that can see the benefits of focusing on the right things and keeping an eye on the right metrics will improve. Teams want to improve their productivity. They want to get better. They want to deliver. Measuring team-based metrics helps them do those things.

10 years ago, I asked if we should or even could measure developer productivity. But I was asking the wrong question. Individual developers are only as strong as their teams. Properly measuring team metrics leads a team toward better outcomes and better software. Instead of measuring individuals, we should encourage our teams to build software better and faster by measuring what they do together.