Hacker News Reader

Comment by raganwald | Hacker News Reader

My beef is mostly hyperbole. But FWIW, my beef is with our industry. Despite my hysterical and contrived rantings, there are a few good empirical results, but those researchers are awfully lonely. There are maybe two(!) good books on the subject, Peopleware and Making Software. How many people making decisions about developing software have read either or both?

Most claims about variances in programmer productivity cite a study that is more than fifty years old. How many programming languages have been developed since that study, and who (if anybody) has done empirical research into deciding whether there are attributes of a language that have a direct bearing on productivity?

I agree with claims that automatic garbage collection, not OO, is the single most important productivity lever to come out of Universities and into industry. How do we know if this is true or false?

View on HN

"There are maybe two(!) good books on the subject, Peopleware and Making Software."

What about Fred Brooks's works? Not being facetious -- curious to know if they slipped your mind or if you just don't rate them.

Criminally underrated comment on the topic: "Part of the problem is that the discourse on methodology is mostly conducted by people who don't themselves do the work. Imagine a bunch of managers working out a 'process' for, say, mathematicians. They'd be laughed out of the room." (gruseom, http://news.ycombinator.com/item?id=406051)

Along that vein, while we're talking scientists -- are there studies on scientist productivity? Even for computer scientists, I'm pretty sure no one's going around debating whether an academic paper is better if it's written by two researchers versus one. The one obvious parallel I can think of is peer review vis-a-vis code review. But that is a process for after the initial work is produced, not one that dictates how someone should conduct the thinking process for their job.

Most claims about variances in programmer productivity cite a study that is more than fifty years old.

A much better study is the one described in Peopleware, which happened about 25 years ago. It found that 10 to 1 differences are common, but also found that much of that difference is explainable by environmental factors.

...and who (if anybody) has done empirical research into deciding whether there are attributes of a language that have a direct bearing on productivity?

In Code Complete Steve McConnell cites research that indicates that programmer productivity in lines of code per day is relatively constant across a wide range of languages. Therefore the conciseness of the language is directly tied to productivity. He then provides a chart estimating the relative productivity of different languages. If I remember correctly (I don't have my books at hand) he was able to cite more research on this in Software Estimation.

In Software Estimation he also discusses the COCOMO II model. His opinion, which I think is reasonable, is that COCOMO II is a bad estimation tool because there are so many factors that people can put their estimates in that they can get out whatever answer they want. HOWEVER it is based on measuring the contribution to actual productivity of many different factors, and so the COCOMO II cost factors are a fascinating source of information on what actually contributes.

I agree with claims that automatic garbage collection, not OO, is the single most important productivity lever to come out of Universities and into industry. How do we know if this is true or false?

We probably never will know. Personally I'd like to suggest that the idea of structured programming (which started with Edsger Dijkstra's Go To Statement Considered Harmful) deserves serious consideration as well.

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 ) 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.

But the industry has nothing to do with computer science. In computer science we have algorithms and abstractions and plenty of real math in computer science.

You are ranting about the art of making people make computers do something. Which is a social science, although a not well developed one, and is not computer science.

Like other social sciences, software engineering is an under-specifiable domain for double-blind studies. TopCoder might be a good example of how far you can take it. It provides a wealth of interesting comparisons that extend to the group of engineers that want to go do TopCoder, across the platforms that TopCoder supports. But it's a little artificial environment and doesn't tell you much about collaboration.

The other problem is that there's more variety and less consensus in judging the work of creative human thought than there is in something like focus group response to commercial messages, or even response to sociolinguistic cues. So all the results of your studies on software have high entropy.

I find this group pretty interesting, Workshop on Duplicating, Deconstructing, and Debunking, http://www.ece.wisc.edu/~wddd/

In particular I find this paper, Is Transaction Programming Actually Easier, illuminating: http://www.ece.wisc.edu/~wddd/2009/papers/wddd_04.pdf

This paper shows that even though students "felt" that STM was harder to understand, their programs tended to be correct!

While with fine-grained locking almost all programs exhibited errors! Even though the students thought they knew what they were doing.

Reply on news.ycombinator.com