If you go to Google and search for “measuring software developer productivity” you will find a whole lot of nothing. Seriously — nothing.
Well, okay, not exactly nothing. You’ll get a ton of links. But almost all of the links you find will talk about how measuring the productivity of software developers can’t be done effectively. Some people will even argue that it shouldn’t be attempted at all. Some others will describe techniques to measure developer productivity, that, well, everyone else knows don’t really work.
There have been many valiant attempts to measure developer productivity, but all seem to end in less than successful territory. (We all know to laugh at “Lines of Code” as a productivity measure). Virtually any objective measurement you can apply to the software development process can be “gamed” into submission.
There are just too many variables to account for everything that goes into the development process. Measuring any one of them, or even a combination of them, simply cannot begin to capture effectively everything that is involved. You can’t pick a surrogate thing to measure, but because of human nature, developers will react in ways that will skew the measurement. Many studies have been done on this topic, with little to show for it. Every software development manager who has to fill out a developer’s evaluation or determine who gets bonuses has struggled with this. Many a leading expert and guru has thought about and researched this thorny topic.
This talk will discuss the futility of trying to *objectively* measure developer productivity and instead will propose a means for making an attempt at an “objectively subjective” way to measure developer productivity.