<div dir="ltr">Once upon a very long time ago we did a project to compare the efficiency of<div>Erlang to PLEX.</div><div><br></div><div>We implemented "the same things" (TM) in Erlang and PLEX and counted total man hours</div>
<div><br></div><div>We did this for several different things.</div><div><br></div><div>Erlang was "better" by a factor of 3 or 25 (in total man hours) - the weighted average was a factor 8</div><div><br></div><div>
They asked "what is the smart programmer effect"</div><div><br></div><div>We said "we don't know"</div><div><br></div><div>We revised the figure 8 down to 3 to allow for "the smart programmer effect" - this was</div>
<div>too high to be credible, so we revised it down to 1.6. (the factors 3 and 1.6 where just plucked</div><div>out of the air with no justification)</div><div><br></div><div>Experiments that show that Erlang is N times better than "something else" won't be believed if</div>
<div>N is too high.</div><div><br></div><div>The second point to remember is that you *never* implement exactly the same thing</div><div>in two different languages (or very rarely) - the second time you do something</div>
<div>you have presumably learnt from the mistakes made the first time you do something.</div><div><br></div><div>If you implement the same thing N times in the same language, each implementation should take</div><div>less effort and code than the last time you did it. What can you learn from this?</div>
<div><br></div><div>The difference in programmer productivity can vary by a factor of 80 - (really it's infinity,</div><div>because some programmers *never* get some code right, so the factor 80 discounts the</div><div>
totally failed efforts) - So given a productivity factor you have to normalize it by a factor</div><div>that depends upon the skill and experience of the programmer.</div><div><br></div><div>There are people who claim that they can make models estimating how long a software projects take.</div>
<div>But even they say that such models have to be tuned, and are only applicable to projects</div><div>which are broadly similar. After you've done almost the same thing half a dozen times</div><div>it might be possible to estimate how long a similar project might take.</div>
<div><br></div><div>The problem is we don't do similar things over and over again. Each new unsolved problem</div><div>is precisely that, a new unsolved problem.</div><div><br></div><div>Most time isn't spent programming anyway - programmer time is spent:</div>
<div><br></div><div> a) fixing broken stuff that should not be broken</div><div> b) trying to figure out what problem the customer actually wants solving</div><div> c) writing experimental code to test some idea</div>
<div> d) googling for some obscure fact that is needed to solve a) or b)</div><div> e) writing and testing production code</div><div><br></div><div>e) is actually pretty easy once a) - d) are fixed. But most measurements of productivity only measure</div>
<div>lines of code in e) and man hours.</div><div><br></div><div>I've been in this game for many years now, and I have the impression that a) is taking a larger and</div><div>larger percentage of my time. 30 years ago there was far less software, but the software there was</div>
<div>usually worked without any problems - the code was a lot smaller and consequently easier to understand.</div><div><br></div><div>Again in the last 30 years programs have got hundreds to thousands of times larger (in terms of code lines)</div>
<div>but programming languages haven't got that much better and our brains have not gotten any smarter. So</div><div>the gap between what we can build and what we can understand is growing rapidly.</div><div><br></div>
<div>Extrapolating a bit I guess a) is going to increase - so in a few years we'll have incredibly smart</div><div>devices which almost work, and when broke nobody will able to fix, and programmers will spend 100%</div>
<div>of their time fixing broken stuff that should not be broken.</div><div><br></div><div>And no I have to figure out why firefox has suddenly stopped working - something is broken ...</div><div><br></div><div>Cheers</div>
<div><br></div><div>/Joe</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 6:44 AM, <span dir="ltr"><<a href="mailto:kevin@funceng.com" target="_blank">kevin@funceng.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello All,<br>
<br>
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.<br>
<br>
If you have any thoughts, please respond on this list or better yet, just add a comment to the blog post:<br>
<br>
<a href="http://funceng.com/2013/09/18/estimation-and-progress/" target="_blank">http://funceng.com/2013/09/18/<u></u>estimation-and-progress/</a><br>
<br>
Thanks,<br>
<br>
Kevin<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>