Development productivity
Published: 2022-10-28 14:36:21

The purpose of productivity measurement is to increase business efficiency. Properly selected and motivated people give better results. A significant part of the costs (and in IT companies - a large part) is the developer compensation fund. Accordingly, the presence of some kind of productivity assessment system allows the team leader to answer questions:

- Will a person be able to work in this team on an equal footing after a probationary period?

- Does the developer have problems with professional skills?

- Is it fair to raise an employee in the category (from Junior to Senior), or is he just constantly flashing before the eyes of management and therefore gets promoted?

When the team grows, then there are questions that must be answered by the CTO:

- And is the overall productivity of the team growing in conditional values?

- How does the team's competence profile change?

Let's go from top to bottom and start analyzing metrics. For example, I will show graphs of one system.

**Dynamics of pull requests**
![Dynamics of pull requests](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aous4gtrwpnmseiw3lu6.jpeg)

The development team is growing, which means the number of pull requests is also growing. The above graph is ambiguous, because it is known for certain that the team is growing, but for some reason the number of pull requests does not follow the growth trend. It may be necessary to check the source of the uploaded data for correctness. Well, or a CTO should panic.

**Code base growth**

![Code base growth](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/39caa9j7bzsavl45en6a.jpeg)

The codebase as a whole is growing. Cheers. But the graph itself will not give anything: we look above at the dynamics of pull requests (they are just not growing). So, we need to figure it out.

**Developer activity by hours and by days of the week**

![Developer activity by hours and by days of the week](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/03q4gmqxrzvdjsy7ii6g.jpg)

At first, it may seem that the graph is useless. You can just see that the maximum number of commits is on Wednesday, and the most productive days are Tuesday and Thursday. But pay attention to the activity at 22.00, which does not disappear. There is also developer activity on Saturdays. This is not very good, we need to figure out who systematically overworks, because developers need to rest: there is such a phenomenon as "burnout", leading to a rapid loss of an employee.

**Security of your codebase**

![Security of your codebase](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7ttau976hwlo4g9k75jl.png)

Everything is built around the Bus factor (BF) metric. Let's take the first line in the illustration — the CLIC service. He has BF = 1.07. In other words, only 1 developer has knowledge of this service. And if he leaves, then you will have to spend a lot of time immersing newcomers in the project. We should find all such services and share the codebase with other developers.

**Productivity of developers of one team**

![Productivity of developers of one team](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xy454rvr0rvedissqajk.png)

The blue dotted line is a certain median of the amount of code created by this development team. The Y-axis shows the absolute values by month. We see that Ivanov and Petrov consistently write less code than other team members, which means they deserve the attention of the team leader. Moreover, the reasons may be quite natural: they are just junior developers or they are super-seniors, who build complex RnD services (more think, less code).