dag@control.lth.se (Dag Bruck) (01/26/91)
In article <2961.279ffcba@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: > Unfortunately for C and C++ users, Smalltalk can provide equivalent > functionality in about 30% less memory based on actual experiences > in rewriting large C programs into Smalltalk. Wouldn't you expect 30% improvement in size and speed after any kind of fundamental rewrite of a system? I believe that the rare possibility to redesign and reimplement a software system, with the experiences from an earlier implementation in your luggage, is far more important than the differences between some reasonable programming languages. > ... Smalltalk's 4x productivity over conventional languages > such as C can not be ignored as a strong indicator of its power. I seem to recall having seen some figures of programmer productivity some years back. I think the figures struck me as interesting but highly speculative. Could anyone present the results from some controlled experiment? I would be interested in knowing - what is the defference between a skilled and an unskilled programmer, in terms of productivity? - what are the tradeoffs between short-term vs. long-term productivity (i.e., hack vs. s/w engineering)? - what is the impact of rapid prototyping? - what is the importance of programming environment vs. programmer skill? Two extreme viewpoints: "a good programmer can work with any environment" and "with a good environment, any programmer is productive." Any pointers would be appreciated. Dag M. Bruck
rueger@itwdo.fhg.de (Michael Rueger) (01/28/91)
In article <1991Jan26.094306.17436@lth.se> Dag M. Bruck writes: >> ... Smalltalk's 4x productivity over conventional languages >> such as C can not be ignored as a strong indicator of its power. >I seem to recall having seen some figures of programmer productivity >some years back. I think the figures struck me as interesting but >highly speculative. > > ... > >Any pointers would be appreciated. Quite a while ago I encountered a *very* interesting paper (unfortunately German) in "Informatik Spektrum, 12/1989" about management of software projects. Besides dealing with management aspects it included some quie revealing facts about programmer productivity. Measuring productivity in LOC (lines of code per man year), nothing seams to have changed over the (quite a lot of) years. 1977 3200 1986 2770 (+/- 900) 1988 4400 (+/- 2000) !!!! Figures are agreed to be highly speculative, but at least it's some some numbers. IMHO a key point in these nonincreasing numbers is the notion of LOC. In 1977 LOC probably is something like Assembler (or at least something quite close like BASIC or COBOL (no flames please)). In 1988 LOC meant C or PASCAL or whatever, so it's not that much difference ?! So for me the key to productivity is reuse, that is the ever increasing power of the measure LOC without the need to design new languages over and over again. Another name used is software IC or just OOP (I'm using Smalltalk-80 BTW). >Could anyone present the results from some controlled experiment? I >would be interested in knowing > > - what is the defference between a skilled and an unskilled > programmer, in terms of productivity? > > - what are the tradeoffs between short-term vs. long-term > productivity (i.e., hack vs. s/w engineering)? > > - what is the impact of rapid prototyping? > > - what is the importance of programming environment vs. > programmer skill? Two extreme viewpoints: "a good > programmer can work with any environment" and "with a > good environment, any programmer is productive." > In the same article meantioned above are some other numbers concerning factors influencing productivity (number describe relative productivity): (the first number applies if the factor is less applicable than normal, the second if it is more applicable than normal) complexity of interface to the customer 4.0 1.0 experience with language 1.0 3.2 general qualification 1.0 3.2 application experience 1.0 2.8 customer influence on requirement definition 2.4 1.0 (!!!!) experience with system 1.0 2.1 complexity of algorithm 2.4 1.0 limits on main memory 2.1 1.0 and of surprisingly low influence complexity of control flow 1.4 1.0 module size 1.25 1.35 A few examples: A difficult interface to the customer (negotations, information flow etc) cuts down productivity to a quarter. A qualified team (factor 3) with experience in the language (2) and the system (6) theoretically gives a 25-fold speedup ! There were some other interesting numbers on optimal team sizes like the fact that productivity decreases on larger teams leading to impossible projects (projects requiring to many LOC in a certain short amount of time). Well it is quite obvious, that one just can not produce 10.000 LOC in a week by assigning a team of 100 people to do the job. Michael Rueger rueger@iml.fhg.de ******** the world is coming to an end ---- save your buffers ***************
tma@m5.COM (Tim Atkins) (02/05/91)
In article <1991Jan28.140735@itwdo.fhg.de> rueger@itwdo.fhg.de writes: > >Measuring productivity in LOC (lines of code per man year), >nothing seams to have changed over the (quite a lot of) years. > 1977 3200 > 1986 2770 (+/- 900) > 1988 4400 (+/- 2000) !!!! These are per man year???? I must be doing something wrong. Most jobs that I've had seem less than satisfied with this amount of productivity per month! Seriously, do any real programmers average 10 lines a day or less? Granted that via reuse this is quite possible and desirable, but even without it? I actually expect and hope LOC count would rise once the available software components are well understood, and of course the code would accomplish more than it did previously. As is well known, LOC is about the poorest measurment of programmer productivity imaginable. Some measurement of time to produce a working solution for a given amount of problem complexity would be much more enlightening. - Tim
rons@microsoft.UUCP (Ron STARR) (02/07/91)
In article <1991Jan28.140735@itwdo.fhg.de> rueger@itwdo.fhg.de writes: ->In article <1991Jan26.094306.17436@lth.se> Dag M. Bruck writes: -> ->>> ... Smalltalk's 4x productivity over conventional languages ->>> such as C can not be ignored as a strong indicator of its power. -> ->>I seem to recall having seen some figures of programmer productivity ->>some years back. I think the figures struck me as interesting but ->>highly speculative. ->> ->>Any pointers would be appreciated. ....(ref to German article deleted).... DeMarco and Lister's book _Peopleware_ includes a bit of information on programmer productivity. Their conclusion is that the work environment has a far greater effect on programmer productivity than choice of language. Of course, they don't consider OOPLs...