6 ms·
"What should we measure to improve developer productivity?" is a decades-old problem for leaders with no clear solution. There finally seems to be some level o
by geekjock 4y ago
"What should we measure to improve developer productivity?" is a decades-old problem for leaders with no clear solution.
There finally seems to be some level of consensus that output metrics like lines of code, # of PRs, and commits, are an ineffective approach.
Lean metrics like cycle time and lead time can be a helpful high-level diagnostic, but they're far from an indicator of effectiveness or productivity.
A new approach being adopted by many organizations is to focus on the actual experiences of developers... the things that slow them down or frustrate them... and turn these into measurements that guide improvement. I'm the founder of getdx.com where we're publishing research on this: http://paper.getdx.com http://paper.getdx.com
- rqtwteye 4y ago“the things that slow them down or frustrate them” Whenever management makes a new attempt at getting more precise estimates I always tell them the only way to get things done is by doing them. So the number one goal should be to remove obstacles, simplify processes and make sure tools work to our benefit. For some reason nothing much ever changes and the question for better estimates returns. It’s pretty weird.
- quickthrower2 4y agoAnything that is routinely easy to estimate can probably be automated away. And so will your competition.
- Cardinal7167 4y ago> "What should we measure to improve developer productivity?" How about nothing? Honest question. I am sick and tired of being treated like cattle. I've never seen a single convincing argument that any metric of my outputs has mapped to some productivity metric in a meaningful way, but I have absolutely seen them weaponized against me and others to punish and fire engineers. All of these metrics have only ever boiled down to a negative reinforcement mechanism, in my experience.
- yamtaddle 4y agoBut if you don't measure them—or if, god forbid, you give them their own offices with doors—they might start to think they're in the professional/upper-middle class, not the middle class!
- hcarvalhoalves 4y agoThis doesn’t work, because then your company would have to measure your value by the value you deliver. That would probably mean having to compensate people like you way better, because software engineers can create immense value. Of course this can’t happen, as we apparently live in a universe where only management have bonus based compensation.
- astrange 4y agoWho’s we? FAANG engineers have bonus and stock compensation.
- geekjock 4y agoI'm a developer and am right there with you. But if you're a decades-old corporation with 10,000 engineers, you need some set of signals to help guide improvements to tools and processes, right? This benefits developers, and there should be a set of signals to enable this.
- closeparen 4y agoYou need objective, measurable signals if you are concerned that developers might be confused or lying. Otherwise you can just ask us. Most people are happy to tell you what the pain points are in their workflow and how they compare to last year's. Maybe you need metrics to quantify specific complaints like "slow" or "crashes a lot." But I feel like most organizations doing this kind of measurement are looking for some kind of Freakonomics "developers think they want X, but what makes them better is actually Y" when they haven't even bothered to ask about, let alone implement, X.
- 4y ago