Can We Measure Developer Productivity?

Can software developer productivity be measured? And if so, how do you measure it? Should you measure it?  This is not just a general topic. This is actually really relevant right now.

Why Is It Important Now?

This topic has been all over the news lately. In case you didn't know, we're having a bit of an economic downturn. Some say recession, some just say slow period, and who knows what it is. But the point is, it's causing people to look at their finances. They're now looking at the productivity. 

Google came out this week and said employees' productivity and focus need to improve. They launched a new initiative called Simplicity Sprint to gather employee feedback on efficiency. 

So, basically saying, the developers aren't producing what they should. Does that mean that they're lazy? Does that mean that they don't have the right tools? Does that mean, and it's actually suggested in many places, that it's this remote work? It is that idea of people not being in an office, and that's why we need to get them back in the office. The fact is that they believe that developer productivity needs to get better.

One thing to point out is this is not the only company saying this. We also have Mark Zuckerberg with Meta's approach here.  Saying that, Meta is also slowing down, and he thinks that a lot of this is due to low developer productivity. 

The problem is that there is no standard way to measure productivity. If there's no way to measure it, how do you know it's down? And furthermore, even if it is somehow down, how do you know if you're improving?

Can you even measure developer productivity? Is there a way to do it? Is it the number of code lines? Is it the number of meetings on a visible calendar? Could you imagine measuring developers based on how many meetings they have? Where the number of meetings equal a productive product of the developer?

Some people think, well, the answer is tracking the right metrics. But metrics aren't really the full solution.

Amazon is notorious for using algorithms and metrics to measure the productivity of warehouse workers. So, why not apply metrics and a data-driven approach to the entire company? Some people feel that this is the answer. It is just finding the right metric. The question is not, should you measure productivity? It's yes, you should measure it. The question is what should you measure, and some people feel Amazon is going in the right direction.

Well, let me say, it didn't end well. At least in the case of gopuff company.  That is a 15 billion dollar software or delivery startup company that stole a bunch of the managers from Amazon, and many people are saying it's their managers' obsession with metrics that killed the company.

So now, we go from how do we measure productivity? Is it metrics? To, well, actually, metrics can destroy a company.

This is an interesting problem. There is not a simple answer; it's not an answer one way or the other, but I think we can all agree that we do want our teams to be better. We do want our developers to be happier, we do want to be more productive, and we want to achieve our business goals better. But how do we do that?  

Can and Should You Measure Developer Productivity?

 Of course, you should measure developer productivity, and I think we've entered a golden age where, suddenly, it is possible. 

Why should you measure developer productivity? How are all of these CEOs going out into the world and saying our teams aren't being productive enough? I would challenge everybody to say, exactly how do you know that? If you're not measuring, you don't know.

So, of course, we need to be able to measure. And then, the question is, can we measure? I think our answer is, finally, yes, absolutely!

So the next logical question is, how do you measure? 

I think it's like anything else. You want to base it off the work that we're doing, and the reason I think we're in a golden age is because employees and organizations invest everyday effort doing code review and monitoring things with Datadog or Century and all of these tools out there.

Fifteen years ago, we didn't have a lot of these tools. We had something behind your firewall that was inconsistently used. But we have these kinds of Primitives in the dev workflow space that teams have adopted, that is capturing all of this actual work. 

So we have the ability to key into these systems and glean information that you can put into a format that's very digestible from all these real systems. So, rather than getting conventional and labeling this thing this way or that way, I'll run a spreadsheet you can actually key into the actual Investments that your organization is making today and get a measure of productivity.

What About Activity as a Productivity Measure?

 Talking about developer productivity, people think about the developer's productivity with the idea that I can measure your output; I can measure mine. I can compare the two and see who's the more productive or better developer.

When I think about it that way, that really bugs me personally. Because I think that's such a poor proxy for this big problem, which is performance. It is not just about how many PRS. I mean, I could be someone who knows how to figure out issues and solve them. It might take me two or three days just to come out with one line of code change that solves the issue. So, if you were looking at output metrics, you would say, “Get rid of him.” You need someone who is much more productive and can get things out every day, ten things a day, but when you look at the impact of the company, you need to see that kind of the bigger picture.

Productivity Is a Team Sport

 Productivity is a team sport. Software engineering is a team sport. We don't accomplish things. We work on things individually, but we're doing this as a team effort, and as your team grows, obviously, it becomes even more so.

And when you have somebody who maybe is even really smart and really productive, but they work in a way that's kind of destructive, like they can accomplish a lot, but they're actually causing the team to not be able to keep along. They're working like super individuals, and the team overall suffers, and the sort of deliverable overall suffers.

So, absolutely, I think you need to focus on how your team is performing. How are the individuals performing? And obviously, the individuals make up that sort of team Dynamic.

So, it's not about your productivity anymore. It's about the productivity of the whole team. Focusing on that instead of just how much you can sling code, make the deadline, and save your team's reputation. But that's a short-term game that is going to be hurting long-term.