This is really a followup question to Is programming in Python faster than in C, C++ or Java? that I also posted on programmers.SE. The first comment seem to challenge the very idea that programmer productivity can be measured to begin with:
Well, since you've restricted the set of possible answers, I just dare a comment by asking another question which should be answered first (imho): Is there a reliable and established metrics for measuring the "productivity of a programmer"?
He later goes on to argue that there are so many ways to measure productivity, but they are only applicable to whatever narrow thing they were analyzing:
Yes, there just "too many" ways which, from my point of view, very often contradict each other. All articles, books, blogs, talks.. I have read or heard with regard to this topic were more or less subjective or narrowed to a very specific set of problems making the results hardly applicable.
Further Joel Spolsky in 2005 wrote a post called Hitting the High Notes:
Let's start with plain old productivity. It's rather hard to measure programmer productivity; almost any metric you can come up with (lines of debugged code, function points, number of command-line arguments) is trivial to game, and it's very hard to get concrete data on large projects because it's very rare for two programmers to be told to do the same thing.
He then reference a CS class where they measured time and quality of software with great variance, after which Joel concluded:
There's just nothing to see here, and that's the point. The quality of the work and the amount of time spent are simply uncorrelated.
Has this issue been tackled by researchers with repeatable results, or do we have no idea how to reliably measure productivity of programmers as a whole, beyond the opinions of individual programmers common-sense and experience?
Guidance towards answering the question
Productivity: (economics) the ratio of the quantity and quality of units produced to the labor per unit of time
So by the very definition of the word productivity, you can arrive at the same level of productivity, but at different points of the spectrum (several units produced, quality of fewer units). As such it's important to declare how productivity changed, and why we think it increased instead of decreased, on the whole. Also if productivity goes up in all imaginable metrics then by any definition, that's being more productive.
Wikipedia on programmer productivity suggest the following dimensions:
- Amount of code that can be created
- Amount of code that can be maintained
- Detecting and avoiding errors
- Software cost estimation
Reliable metrics in this case means:
If different groups of people do the same change, they will see the same results once controlled for external factors.
Assumption of no malice: The programmers being measured aren't trying to intentionally circumvent the metric, by for instance adding extra lines of code when the metric is lines-of-code.
Related on programmers.SE:
