Ask HN: Is it possible to measure developers productivity?
I've interacted with older developers and according to them you can't measure developers productivity.
There is always a way to 'game' the system.
There is always a way to 'game' the system.
From the perspective of measuring job performance, yes that can be measured (some of it is subjective, not metrics) but not productivity. They are slightly different in that as a manager I want to see people performing well, growing in their career, learning new things, getting work done, etc. If you use the lens of productivity there is a different intent that you can somehow increase productivity by expecting more numbers of X, Y or Z. So if you set a silly goal of close X tickets/month its meaningless and if you tie raises/bonuses to it expect it to be gamed. Instead if you use metrics of things (ticket counts) and look for outliers as an indicator, then that can be helpful if someone is struggling for what could be many different reasons (under-skilled, requirements keep changing, personal life stuff, etc.)
Subjective things can be measured but its more of a thumbs-up/down/middle measurement. Being helpful to other people on a software team/mentoring is subjective, so is good software design. Once you start putting numbers on subjective things and expecting better numbers its going to fall apart and be gamed.
The problem is with bad or lazy management that wants charts and thinking they can squeeze more out of workers by counting things and "make chart go up".
The old programmer joke about writing a script instead of doing the same thing twice, hides a truth that the value of our work is doing stuff we haven’t done before.
But, if you have never done a task before how do you measure it? And if you have done a task before, why are you doing it again, can’t you reuse what you did last time?
There’s factors out of most devs control that influence their productivity—a mark of a senior dev (IMHO) is someone who understands this and actively unblocks themselves and others.
So no, I don’t think you can directly measure a devs productivity.
Measuring a team’s productivity is equally challenging, as the team is affected by things out of their control too, and the team is also doing work that hasn’t been done before.
Instead, I think looking towards the health and quality metrics of the team’s output (say a service they created/maintain), the health of the team, and actually speaking to engineers is the best chance we have of understanding the how well the team is working.
The problem is that few organizations are willing to explicitly state their accepted trade offs. They want everything.
So, say that the goal is feature release so that sales can satisfy a major client and land the contract. Your options are:
1. Have the feature quickly, but buggy. Well enough to demo, but regular use would see problems.
2. Have the feature work well, but build it more slowly. Tell the client "no."
3. Dedicate more hours of development time to the feature and cut other priorities to have it faster (this only works up to a point, so hiring 20 devs for a week onto a team of 10 doesn't cut the time from 3 weeks to 1).
Any of those are possible.
But getting firm agreement on one of those is something I have never seen. If a company incentivized speed, quality, or flexibility, it would get it as long as it accepted the trade offs. Instead, the company usually wants to measure speed while complaining about reduced quality.
https://thedailywtf.com/articles/The_Brillant_Paula_Bean
But when there's a semblance of competence, then telling how productive a developer is isn't all too practical. Lines of code? A good developer will be just as likely to remove unnecessary lines that already exist as they will add new ones. Git commits? A look at any major open source event offering t-shirts for contributions can show you how that can be gamed. Tasks done on time? Nope, planning is often flawed at best.
It's not like a production line.
Too many companies focus on productivity and throughput instead of impact (of their features). So they produce bad features faster and faster.
One thing thats often underestimated here is the impact a bad feature has over time. Not just when its released and fails, but also support, maintenance, tech debt, additional complexity in the product and the overhead this has on trying to improve things in the future.
The question is: what is productivity and why do you want to measure it. Because the crux of the issue is whether what you're measuring really is productivity. The things that you are capable of measuring are often easy to measure, but poor indicators of productivity. And even then, is productivity what you want? The productivity needs to be aligned to the business goals. If you set engineers productivity targets they'll find the easiest way to meet those targets but they might not align to the business.
But I think it's more important to look at how you actually manage people. The best way to get good work out of people is to make sure they have the information and resources they need to do the job, they're free from distractions, they have autonomy and authority to do what they need to get the job done, they're working in a high trust environment, and their achievement is recognised. None of those things are improved by measuring productivity, and trust, autonomy and recognition are actively hurt.
By defining productivity for an engineer what you're saying is "You no longer decide how to best serve the company, I decide that, and you just follow what I say". Good luck, suddenly all the responsibility is on you - and you don't even control the outcome.
The first question to myself: Become the same developer less productive if you raise the salary?
Which originates in distrust in yourself.