17 ms·

Also I think in the 60s there were analysts, the people who solved the problem and programmers, the people who converted the solution to code. Anyway, in the 6

Also I think in the 60s there were analysts, the people who solved the problem and programmers, the people who converted the solution to code. Anyway, in the 60s the profession was in its infancy, so I'm not sure how much studies from this era matter today.

andrewstuart 9y ago
I vaguely recall some of those big statements about programmer productivity came from observations of the relative performance of programmers developing IBM mainframe operating systems in assembly language. I bet you'd surely find 10 to 1 or 100 to 1 differences in programming productivity on a project like that following waterfall methodology in the 1960's.
nnfy 9y ago
I also wonder how the productivity gap has been affected by modern development technology, or even the languages themselves.
- acdha 9y ago
  It definitely affects your ability to compare studies over a long period of time – e.g. there was a huge shift in what programming work looked like during the progression from submitting code as batch jobs with a turnaround time measured in hours, to having a terminal on a shared system (where compilation was still a slow process), to individual workstations. That changes some of the skills significantly – i.e. reasoning about code on a whiteboard isn't useless but it's not a critical skill the way it was before everyone had an editor running code checks continuously, interactive debugger, etc. I think Fred Brooks was right to argue[1] that we're not going to see dramatic further improvements because we're at the point of diminishing returns on overhead and most of the remaining work is actually inherent to whatever problem is being solved. The closest we've probably come to a change on that scale was the rise of cloud technology shrinking the feedback cycle for testing but I don't think that's been an order-of-magnitude change for most people. 1. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet

andrewstuart 9y ago

I vaguely recall some of those big statements about programmer productivity came from observations of the relative performance of programmers developing IBM mainframe operating systems in assembly language. I bet you'd surely find 10 to 1 or 100 to 1 differences in programming productivity on a project like that following waterfall methodology in the 1960's.

nnfy 9y ago

I also wonder how the productivity gap has been affected by modern development technology, or even the languages themselves.

acdha 9y ago
It definitely affects your ability to compare studies over a long period of time – e.g. there was a huge shift in what programming work looked like during the progression from submitting code as batch jobs with a turnaround time measured in hours, to having a terminal on a shared system (where compilation was still a slow process), to individual workstations. That changes some of the skills significantly – i.e. reasoning about code on a whiteboard isn't useless but it's not a critical skill the way it was before everyone had an editor running code checks continuously, interactive debugger, etc. I think Fred Brooks was right to argue[1] that we're not going to see dramatic further improvements because we're at the point of diminishing returns on overhead and most of the remaining work is actually inherent to whatever problem is being solved. The closest we've probably come to a change on that scale was the rise of cloud technology shrinking the feedback cycle for testing but I don't think that's been an order-of-magnitude change for most people. 1. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet