Joe Armstrong on Programmer Productivity

Joe Armstrong on Programmer Productivity.txt

LINK: https://groups.google.com/forum/#!msg/erlang-programming/OiyGQ4UHqxw/HgGma01CGqYJ



Once upon a very long time ago we did a project to compare the efficiency of
Erlang to PLEX.

We implemented "the same things" (TM)  in Erlang and PLEX and counted total man hours

We did this for several different things.

Erlang was "better" by a factor of 3 or 25 (in total man hours) - the weighted average was a factor 8

They asked "what is the smart programmer effect"

We said "we don't know"

We revised the figure 8 down to 3 to allow for "the smart programmer effect" - this was
too high to be credible, so we revised it down to 1.6. (the factors 3 and 1.6 where just plucked
out of the air with no justification)

Experiments that show that Erlang is N times better than "something else" won't be believed if
N is too high.

The second point to remember is that you *never* implement exactly the same thing
in two different languages (or very rarely) - the second time you do something
you have presumably learnt from the mistakes made the first time you do something.

If you implement the same thing N times in the same language, each implementation should take
less effort and code than the last time you did it. What can you learn from this?

The difference in programmer productivity can vary by a factor of 80 - (really it's infinity,
because some programmers *never* get some code right, so the factor 80 discounts the
totally failed efforts) - So given a productivity factor you have to normalize it by  a factor
that depends upon the skill and experience of the programmer.

There are people who claim that they can make models estimating how long a software projects take.
But even they say that such models have to be tuned, and are only applicable to projects
which are broadly similar. After you've done almost the same thing half a dozen times
it might be possible to estimate how long a similar project might take.

The problem is we don't do similar things over and over again. Each new unsolved problem
is precisely that,  a new unsolved problem.

Most time isn't spent programming anyway -  programmer time is spent:

    a) fixing broken stuff that should not be broken
    b) trying to figure out what problem the customer actually wants solving
    c) writing experimental code to test some idea
    d) googling for some obscure fact that is needed to solve a) or b)
    e) writing and testing production code

e) is actually pretty easy once a) - d) are fixed. But most measurements of productivity only measure
lines of code in e) and man hours.

I've been in this game for many years now, and I have the impression that a) is taking a larger and
larger percentage of my time. 30 years ago there was far less software, but the software there was
usually worked without any problems - the code was a lot smaller and consequently easier to understand.

Again in the last 30 years programs have got hundreds to thousands of times larger (in terms of code lines)
but programming languages haven't got that much better and our brains have not gotten any smarter. So
the gap between what we can build and what we can understand is growing rapidly.

Extrapolating a bit I guess a) is going to increase - so in a few years we'll have incredibly smart
devices which almost work, and when broke nobody will able to fix, and programmers will spend 100%
of their time fixing broken stuff that should not be broken.

And now I have to figure out why firefox has suddenly stopped working - something is broken ...

Cheers

/Joe