app/notes/20170522-0230.md
Core Metric for Developer Productivity
core-metric-developer-productivity
1495420256
A lot of software companies are concerned about the concept of developer
productivity and maximizing the amount of output each engineer produces.
The problem is that few companies measure productivity in any quantitative
manner, instead using subjective metrics like developer happiness or
irrelevant metrics like lines of code. Additionally, companies frequently
confuse product management processes, like agile development, with helping
software engineering metrics. This results in software being developed slowly
and quite a lot of grumbling when the scrum master burns hours of each
engineer's team on sprint planning.
Looking around, I think that the core metric for developer productivity should
be the average frequency of the edit/test/debug cycle. In all but the most
intellectually challenging of programming problems, there is a clear direction
of what needs to be built but the limiting factor is making sure the
programmer's code works as intended. Optimizing the edit/test/debug cycle
therefore makes developers produce value faster. Many features in IDEs and modern
development practices are aimed at shortening steps in the cycle, reducing
the number of cycle iterations needed to complete the development work, or
helping developers stay within the cycle. Indeed, Joel Spolsky's
[famous test for programming environments](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/)
can be summarized as checking the health of a development team's edit/test/debug
cycle. I therefore hope that when you evaluate processes and products to help
be more productive, you think of how it will benefit your edit/test/debug cycle.