I'm guessing that programmer productivity research boils down to a bias against qualitative research. Most "pure" CS researchers (or software engineering for t

I'm guessing that programmer productivity research boils down to a bias against qualitative research. Most "pure" CS researchers (or software engineering for that matter) probably have backgrounds where qualitative studies don't score you much juice in the academic research world. My (limited) exposure to qualitative data analysis is hearing from researchers in public health and public policy how they use coding (not programming, see http://en.wikipedia.org/wiki/Qualitative_research http://en.wikipedia.org/wiki/Qualitative_research ) to build some reasonable data set for analysis. To do that for programming, you'd really like to get access to a number of different organizations (from IBM/Oracle/Microsoft all the way down to the YCombinator funded groups) to try and collect data. But what you'd be studying would have limited value to those sources in the end. I'm also not sure how you'd design any controls into the data collection. Another big issue out there is that if you've ever experienced the difference in productivity that using "the right programming language for the right problem," you KNOW there is a difference. But how much? More importantly, can we measure the effect on "getting things done" from this productivity boost/effect? Personally, I've found that I have to be rather immersed in a language or feature for some time before it resonates for me. But I'm drawn to little bits of cleverness in languages rather than in the big picture of what it offers. Because of this attraction to the shiny, interesting parts of languages, I tend to ignore the dark, dusty corner cases that pop up.