Geek karma points to all those who help!
“Last year, over 1800 developers around the world responded to our previous report. I’m considering to donate a body part if we could do more than that again this year.” -Oliver White, Head of RebelLabs and Amateur Vine Videographer
How do you measure developer productivity?
Just asking this question is an invitation to a holy war. It has been discussed again and again that comparing developer productivity by any quantifiable metric will ignore many important factors. In different projects working on different tasks a developer will produce wildly varying amount of lines of code, tasks solved, bugs fixed and support cases handled. So any of those “work” metrics are not adequate for a comparison.
However, it is possible to measure developer teams. This is where the law of large numbers starts working for you and some of the wide variations start evening out. Even then, it’s not quite possible to measure productivity as such (as it’s unclear how to measure what is being produced).
Instead, we decided to measure three aspects that associate hugely with productivity:
- Predictability – How predictable are your releases? How late do you release? What changes occur during development? Etc.
- Quality – What sucks about your code after it’s released? Is there an “industry average” for quality? How does quality depend on engineering tools and practices?
- Technical debt – What actions, like refactoring, builds, etc, do you take to reduce technical debt? How does this impact predictability and quality? Etc.
Would you help us out? We’d love to collect as many responses as possible, so that we can create another awesome report on it all. Ping @ZeroTurnaround to get involved, help us share/promote and even take part in some of the analysis. We need you! (oh, in case you missed it in the Vine video, here is that link again: http://0t.ee/dpr13