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?
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.
"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.
tl;dr:
Areas of computer science:Theory of computation, Algorithms and data structures, Computer elements and architecture,Computational chemistry,Computational physics,Artificial Intelligence,Natural Language Processing, Cryptography,Image processing, etc
Dijkstra was even more direct to the point: Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians
What does Computer "Science" have to do with programmer productivity? That's like claiming Physics is not a science because you can't measure physicists' productivity effectively.
Yep, we really need to get on fixing all of the terms related to the various computing disciplines.
Companies only confound this further when they want "computer science" degrees, when they really want software engineers. And most software engineering programs I've been exposed to are a joke. Maybe I just need to get out more...
I also have no real ideas or thoughts on how "we" need to "fix" this somehow. Just frustration.
@raganwald dude I understand your need for publicity/ higher page rank by exploiting stupidity of the Web Programmer/Dev/Rubyista/Web Designer etc who are here, but seriously after looking at your resume I hope that you understand what "Computer Science" is, please go to any good CS department {MIT, UCB, CMU, Stanford, Cornell, UIUC} in USA and ask the PhD students + Profs, on how important question about programmer productivity is to them.
And see what you get.
The explosive growth in CS is due to faster processors, larger memory and novel algorithms (a.k.a page rank and other) and not at all because programmers became hyper efficient. You cant make an O(n^3) algorithm to O(n) by making writing programs easier. The aim of computer science is to increase and study ability of computers and the ability of humans is hardly an important factor.
The idiocy at this forum amazes me, sure you can write your crappy Web 2.0 social photo sharing crap in 5 minutes in Ruby but to by frank no one in CS academia gives a shit about it.
I think there's some level of equivocation going on in this article.
P1. Computer Science has to do with computers.
P2. Science is more than formal systems, namely empirical evidence and studies.
C. Computer Science is incomplete if it does not incorporate empirical evidence.
The problem as I see it is not that Computer Science is not Science in the sense that maybe Chemistry and Biology is a science. It's called "Computer Science" not "Computer" + "Science". The term is atomic, in my opinion and you can't really draw the word "Science" out of the name of the field and derive some kind of meaning out of it. CS tends to hang out somewhere between the maths and sciences, but not fully one or the other. I'm not sure how you would go about applying the scientific method to programming.
Also, I think the beef is with software engineering as stated before.
While I agree that "Computer Science" is a bullshit term (would be more accurate to call it something along the lines of "Computation Theory" or "Computation Mathematics"), this article misses that point and attacks the term for the wrong reasons. I call bullshit on his understanding of what computer science is.
And for what it's worth, I think Computer Engineering isn't a particularly strong engineering discipline either...
Who cares about programmer productivity? The whole notion of trying to quantify, measure and predict it is anti-thematic to what's going on at Y Combinator.
Want to see programmer productivity? I'll show you it to you in retrospect. Tools?!?! Languages?!?! How about passion and motivation???
If you're a big company trying to implement the next big thing, just buy it or hire someone with a track record of success.
21 comments
[ 3.2 ms ] story [ 62.5 ms ] threadMost 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?
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.
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.
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.
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.
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.
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.
tl;dr: Areas of computer science:Theory of computation, Algorithms and data structures, Computer elements and architecture,Computational chemistry,Computational physics,Artificial Intelligence,Natural Language Processing, Cryptography,Image processing, etc
Dijkstra was even more direct to the point: Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians
Companies only confound this further when they want "computer science" degrees, when they really want software engineers. And most software engineering programs I've been exposed to are a joke. Maybe I just need to get out more...
I also have no real ideas or thoughts on how "we" need to "fix" this somehow. Just frustration.
The explosive growth in CS is due to faster processors, larger memory and novel algorithms (a.k.a page rank and other) and not at all because programmers became hyper efficient. You cant make an O(n^3) algorithm to O(n) by making writing programs easier. The aim of computer science is to increase and study ability of computers and the ability of humans is hardly an important factor.
The idiocy at this forum amazes me, sure you can write your crappy Web 2.0 social photo sharing crap in 5 minutes in Ruby but to by frank no one in CS academia gives a shit about it.
P1. Computer Science has to do with computers.
P2. Science is more than formal systems, namely empirical evidence and studies.
C. Computer Science is incomplete if it does not incorporate empirical evidence.
The problem as I see it is not that Computer Science is not Science in the sense that maybe Chemistry and Biology is a science. It's called "Computer Science" not "Computer" + "Science". The term is atomic, in my opinion and you can't really draw the word "Science" out of the name of the field and derive some kind of meaning out of it. CS tends to hang out somewhere between the maths and sciences, but not fully one or the other. I'm not sure how you would go about applying the scientific method to programming.
Also, I think the beef is with software engineering as stated before.
And for what it's worth, I think Computer Engineering isn't a particularly strong engineering discipline either...
I think Computer Engineering isn't a particularly strong engineering discipline
yeah thats why the silicon chip that is running your machine crashes every few seconds while performing billions of calculations.
Seriously dude have you studied "Any" Engineering discipline at a good college?
You seem to be full of stupidity.
Want to see programmer productivity? I'll show you it to you in retrospect. Tools?!?! Languages?!?! How about passion and motivation???
If you're a big company trying to implement the next big thing, just buy it or hire someone with a track record of success.