[erlang-questions] Software Estimation and Progress Tracking
Thu Sep 19 14:03:52 CEST 2013
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
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
in two different languages (or very rarely) - the second time you do
you have presumably learnt from the mistakes made the first time you do
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
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
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
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
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
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 no I have to figure out why firefox has suddenly stopped working -
something is broken ...
On Thu, Sep 19, 2013 at 6:44 AM, <kevin@REDACTED> wrote:
> Hello All,
> I recently wrote a blog post on software estimation and progress tracking
> for functional languages. Unfortunately, the post was not terribly
> substantive and posed more questions than it answered. Since the Erlang
> community seems to have a lot of good practical experience on various sizes
> of commercial projects, I wondered if anyone here had experience with
> estimation and progress, particularly as it differs (or perhaps doesn't)
> when using Erlang as opposed to imperative languages.
> If you have any thoughts, please respond on this list or better yet, just
> add a comment to the blog post:
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions