Yannis's Law: Programmer Productivity Doubles Every 6 Years
I keep hearing aphorisms about the "software crisis" and the lack of progress
in software development. I have been programming for over 15 years, and I
find such claims to be completely false: I am convinced that I could reproduce
with today's tools the work of a competent programmer of 15 years ago in a
small fraction of the time.
By analogy to Moore's law and (more appropriately, because of its intention
to provoke, rather than predict) Proebsting's
law, I propose that programmer productivity doubles every 6 years.
To support the quantitative part of my claim consider the following observation.
In his classic paper "On the Criteria to Be Used in Decomposing Systems into
Modules" (1972), David Parnas writes:
The KWIC index system accepts an ordered set of lines, each
line is an ordered set of words, and each word is an ordered set of characters.
Any line may be "circularly shifted" by repeatedly removing the first word
and appending it at the end of the line. The KWIC index system outputs a listing
of all circular shifts of all lines in alphabetical order. This is a small
system. Except under extreme circumstances (huge data base, no supporting
software), such a system could be produced by a good programmer within a week
or two.
The year is 2003 and I would not consider a programmer to be good (this
includes familiarity with tools) if they cannot produce the KWIC system within
an hour or two, instead of a week or two in 1972. This constitutes
an increase in productivity by a factor of 40 over the course of 31 years,
or over 12.5% per year, which results in a doubling of productivity every
6 years.
Note that none of the tools used by the modern "good programmer" is particularly
suited to the specifics of the KWIC system: the problem has to be solved "from
scratch", so to speak, although the starting point is different now than
it was in 1972.
This impressive progress is arguably the cumulative result of reusable software
entities, better system tools, better programming languages, better CS education,
but also good use of faster machines that allow us to ignore low-level overheads
and favor slightly less efficient but convenient solutions.