Measuring Developer Productivity

Companies and teams have different metrics for measuring developer productivity. Some use lines of code, others story points, and some use the number of tasks completed. One of the more meaningless metrics is probably the number of merge requests.

In reality, companies do this because they feel the urge to take control of the productivity of development teams. Therefore, they need to measure not only team velocity but also individual velocity and productivity. There is nothing wrong with the intention. Companies have goals and plans, and they want to be reasonable.

However, there’s something about software development work that is often overlooked: it doesn’t deal with computers, but with people, and people don’t act linearly.

Another fact about people which makes them different from code and computers is that they are complex and inexact. They often don’t act rationally and are susceptible to emotions and external factors.

Therefore, many times the metrics and measurements, even though they sound good in theory, end up backfiring and being abused, not always intentionally but sometimes intentionally by management or individuals.

So what is the solution? If we want to improve developer productivity, how do we measure the productivity in the first place? Can we even measure productivity in a meaningful and applicable way? Can we, for example, see the effect of adopting a new agile approach or a new technology on the productivity of the team?

These are the questions I would like to find the answer to. It’s not only important to know the answer as an individual who works for a company but also as a company that wants to improve the productivity of its development teams.

Or maybe even as someone who wants to implement something on their own. How do you measure and improve your own productivity? When you’re not dealing with a manager who believes more code equals more productivity, how do you measure your own productivity and improve it?