How to measure the productivity of a developer?

How to compare the productivity of developers? Is it possible at all? Is the more productive developer also a better developer? How do increase your productivity? These are all topics for this article.

Why does it make sense to measure the productivity?

Let’s start at the beginning. Why would anyone measure the productivity of the developers? I think it all comes from management side. The management needs to have countermeasures. The management needs to know how good, how productive are the developers to decide about salaries and promotions. And of course the goal of the management is to increase productivity, but how could they prove that they are successful in this field without having a clear measurement methodology? One of the definitions of productivity is result per time. But can result be quantified? The sales team needs to quantify the results to be able to set prices for tasks and projects. Can they do it in a trivial way?

I think the answer is for all of these questions. It is not possible to quantify productivity and result. If you are telling the programmer A is more productive than programmer B that is only your personal opinion, but nothing objective. Let’s see why I am thinking like this.

Measurement methods

There are several measurement methods for productivity I read about or I experienced. I’m trying to list them and show one by one why are they not really correct.

1. Lines of codes / day
   
   I think this is the easiest one to prove that it’s totally bullshit. I can implement the same feature in 100 lines, or in 10 line by using the built in functions of the environment. From quality point of view reusing already working and tested features is much better, than reinventing the  wheel, but it can take more time to figure out which functions are to be used. So if I’m choosing the 10 line solution I’m pretty sure that my LoC/day will be less, than by choosing the first solution.
   
2. Number of commits / day
   
   A commit can be small, a commit can be big. A commit can be trivial or can be difficult. Sometimes it takes days to find the root cause of a bug and to fix it I just need to modify one line and push it in one commit after long days of investigation. Other days I’m implementing small and trivial new features, pushing one feature per commit and I can implement 4-5 small features one day. Am I unproductive at bug fixing? I don’t think so...
   
3. Achieved features / day
   
   
   This is also connecting to the previous point. Sometimes to implement a new feature no investigation is needed, can be done fast, sometimes it takes long days to figure out how a new feature can be implemented in the current environment. And a user of the program can not see the difference, sometimes easiest features are the most valuable ones for the users.
   
4. Estimated hours / used hours
   
   It is also a popular strategy that someone (the developer himself, a technical lead or the team together) is doing a time estimation on the task and later on this estimated time is handled as target. So if you are achieving the task faster than the estimated time you are very productive, if it takes longer you are unproductive. What is wrong here? Who is doing the estimations? If the developer himself than he just need to overestimate everything and he will be the most productive programmer of the world. If a technical lead did it or the team together the situation is a bit better, but in a lot of cases, especially if you don’t have deep knowledge about the code base it is not easy at all to make estimations. I often face with issues, which were not counted at all and takes long time to solve them and it also happened multiple times that I expected a task to be really difficult to achieve and I found an easy solution in one hour. In this can it is again not really about productivity, rather about luck.
   
5. Earned money / day
   
   
   This method is mostly used by freelancers. They are just measuring their productivity in earned money / day. Well if you are encounting money as result than it is correct. But what about days when you need to reinstall your working environment or learn something new? You are not earning anything, but you are working hard all day around. Are you an unproductive developer on that days? No I don’t think so. Or what is the difference if you are developing the same feature for an open source project or for a well-paying customer? Does it make any difference in your productivity? No, it doesn’t.

Connection between productivity and quality

Another important point is the connection between productivity and quality. I think that is common that none of them can be quantized. You can not prove about the quality of your work that it is better than the quality of a colleague. Simple there are too many perspectives.

But what I wanted to say here, that it is faster to produce a code with worse quality: don’t think about tests, code maintainability, documentation etc. For sure you will be faster (more productive) on that one task. But later, when it needs to be extended, or a bug is appearing you will losing all your productivity at figuring out the shit what you have written. You need to find a compromise between quality and productivity.

Productivity of team vs. productivity of an individual

Most programmers are working in teams, but does it make sense to measure the productivity of individuals in this case?

Let me make an example: during the last days I was working from home, I finished much most tasks as I could finish in the office. But after two days my colleagues started to call me, because they had technical issues, which were blocking them. So until I was personally mega effective my teammates were blocked, because I was not there to help them. The summarized productivity of the team was bad due to this issue. If I’m supporting the team mates then my personal productivity will be worse and the team productivity will be higher. That’s why I think measuring of productivity on a personal level is really counterproductive. It motivates developers to support their colleagues what is making the whole development slower. I measurement of productivity is needed, please do it on team level!

What are the influencers of productivity?

The productivity depends on thousand of things. I won’t be able to give the whole list, so I’m just mentioning the most important ones: the developer needs to have the right technical knowledge for the tasks, good experience on the piece of code, a good working environment (good hardware, calm environment), unnecessary meetings and communication should be avoided, good mental state is needed and maybe one of the most important point is the motivation. This topic is such complex that I will write a seperate blog post about that.

Summary

As you can see productivity is a really difficult, but also important topic. I would suggest to avoid quantifying productivity and if it is a must to do it, rather do it on team level, than on personal level.