Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!xanth!mcnc!duke!romeo!crm From: crm@romeo.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng Subject: Re: Programmer productivity Message-ID: <16230@duke.cs.duke.edu> Date: 28 Nov 89 22:12:01 GMT References: <16170@duke.cs.duke.edu> <34819@regenmeister.uucp> <16186@duke.cs.duke.edu> <463.256f438b@devsim.mdcbbs.com> Sender: news@duke.cs.duke.edu Reply-To: crm@romeo.UUCP (Charlie Martin) Distribution: na Organization: Duke University CS Dept.; Durham, NC Lines: 82 In article <463.256f438b@devsim.mdcbbs.com> jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.) writes: >In article <16186@duke.cs.duke.edu>, crm@romeo.cs.duke.edu (Charlie Martin) writes: >> >> The source line of code measure is used precisely BECAUSE it is simple >> and objective (see e.g. _Software Engineering Metrics and Models_, Conte >> et al., or _Software Engineering Econonics_, Boehm.) One reason it is >> objective is that it presumes that the source code being counted fits >> other constraints on its form that constrain away pathological cases >> like the above. > >While I hate to rain on your parade, In 1984 Dr. H. Callisen and S. Colborne >of Magnavox Advanced Products and System Company in Torrance Ca. puplished >a paper in Europe (I have a copy of it somewhere... ) on 'S.A.F.E. Syntatical >Analysis For Estimation'. I presented a paper that was related to it (I was >also working on the project) in October 1984 to the International Society of >Parametric Analysts called 'Designing and Creating an Expert Opinion Database >Using Delphi Techniques'. > If the point of "don't want to rain on [my] parade" is that SLOC isn't the best conceivable metric, or perhaps isn't the best one currently available, hell, it don't hurt MY feelings none. But these are two seapate questions, I think. One point had been that SLOC was not a good metric, that the whole idea of measures of productivity for software engineering (and all engineering, for that matter) was ludicrous and unscientific, not to mention immoral and fattening. In fact (it was alleged) SLOC was not a metric at all in the sense that it did not fulfill the mathematical definition of a metric. Now, I think this are all incorrect notions, and so far I've not seen much in the way of scientific support for them. The peculiarity of SLOC is that for all the paradoxes and pathological cases that can be presented, they seem to be nearly as predictive as other metrics of program size and are very cheap to compute. (They also fit the mathematical definition, if anyone really cares.) The paper that I recall showed that SLOC and other measures correlated to about the 0.9 level, not bad at all for something that seems to be in large part psychological in nature. The second point, which you appear to raise, is whether or not they are a GOOD metric in the sense that they are more effective than other metrics. I don't doubt that they are not. >.... Using lines of code to >determine the cost of creating a software application is about the same as >having a contractor estimate the cost of your new home by computing the number >of nails he will have to use to build it. One of the things I like least about most software engineering arguments is that we so quickly forget about evidence and proof and devolve to metaphor. In this case, I'd just have to point out that number of nails is likely to be predictive of the cost within, oh, 30% or so, so long as the house is frame construction and the cost weighting factors takee into account the cost of other houses built to code in that area in the near past. The reason is that, other things being equal, carpenters TEND to use the same number of nails to build ten running feet of wall, and that and other costs correlate well with square feet of floor space. But can't we SOMEHOW find a way to make software engineering more scientific than that? > >The basis of SAFE and the EODB ... > >If this seems rather sketchy, I apologize, but getting the concepts of a major >published paper and a two hour talk into a few lines of bandwidth at 0200 in >the morning isn't the easiest task in the world. If you are interested in >obtaining a copy of the SAFE paper, send me Email and I will attempt to get the >Library of Congress identifier to you (or at least the name of the Journal that >it was published in). > I would love to read the paper, and rather than EMAIL I'd suggest that you go ahead and post; good work shouldn't be hidden. It fits in rather neatly with some notions I've had about using Kolmogarov complexity of specifications.... Anyway, thanks for the info, and I'd very much like the pub refernce. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) Brought to you by Super Global Mega Corp .com