06.12.07
Review: Some basic determinants of computer programming productivity
Some basic determinants of computer programming productivity by Earl Chrysler (1978) measured the (self-reported) time it took professional programmers to complete COBOL code in the course of their work and looked for correlations.
He correlated the time it took with characteristics of the program and, not surprisingly, found a bunch of things that correlated with the number of hours that it took: the number of files, number of records, number of fields, number of output files, number of output records, number of output fields, mathematical operations, control breaks, and the number of output fields without corresponding input fields. This is not surprising, but it is rather handy to have had someone do this.
He then looked at various features of the programmers themselves to see what correlated. He found that experience, experience at that company, experience in programming business applications, experience with COBOL, years of education, and age all correlated, with age correlating the most strongly. (The older, the faster.) This was surprising. I’ve seen a number of other academic studies that seemed to show no effect of age or experience. The Vessey paper and the Schenk paper (which I will blog about someday, really!), for example, have some “experts” with very little experience and some “novices” with lots of experience.
The academic studies, however, tend to have a bunch of people getting timed doing the same small task. Maybe the people who are fastest in small tasks are the ones who don’t spend much time trying to understand the code — which might work for small tasks but be a less successful strategy in a long-term work environment.
Or the paper is just messed up. Or all the other papers are messed up.
Gotta love research.
Update: Turley and Bieman in Competencies of Exceptional and Non-Exceptional Software Engineers (1993) also say that experience is the only biographical predictor of performance. (“Exceptional engineers are more likely than non-exceptional engineers to maintain a ‘big picture’, have a bias for action, be driven by a sense of mission, exhibit and articulate strong convictions, play a pro-active role with management, and help other engineers.”)
Update update: Wolverton in The cost of developing large-scale software found that the experience of the programmer didn’t predict the routine unit cost. It looks like he didn’t control for how complex the code written was.
Charlie Loyd said,
June 14, 2007 at 3:46 pm
Maybe this is a cheap shot, but I wonder if it’s really wise to draw conclusions about programming from Cobol programming. We don’t judge professional sports training regimens by performance in three-legged races.
ducky said,
June 14, 2007 at 4:07 pm
Oh, no doubt!
Coding in Cobol in 1978 clearly is different from coding in e.g. Java in 2007. Syntax coloring, easy cross-references, findbugs, etc etc etc are all very good things. Life is different now.
Unfortunately, there are very few studies on programmer productivity *period*. It’s lousy data, in some ways, but it’s the only data I have.
Also, note that me doing a review of a paper is NOT an endorsement of the paper. I’m reviewing the papers so that other people can choose whether or not to read the papers themselves.
Hmmm, I think I’ll go and stick “Review:” in the title of blog posts that are reviews…
Kannan Deivasigamani said,
May 3, 2016 at 4:31 pm
Jalics(1989) did a research paper related to efficiency I believe…. This might be a bit more recent but does not provide a way to measure efficiency or estimation technique. Even though he has used COBOL as a reference, some of his insights still are applicable in several of the current generation languages and BI languages such as SAS seems true in several organizations.
Jalics, P. (1989). Realizing the performance potential of COBOL. IEEE Software, 6(5), 70-79. doi:10.1109/52.35591