Xref: utzoo comp.software-eng:2549 comp.misc:7516 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!ukma!rutgers!att!cbnews!kww From: kww@cbnews.ATT.COM (Kevin W. Wall) Newsgroups: comp.software-eng,comp.misc Subject: Re: Programmer productivity Message-ID: <11825@cbnews.ATT.COM> Date: 30 Nov 89 03:58:37 GMT References: <16186@duke.cs.duke.edu> Reply-To: kww@cbnews.ATT.COM (Kevin W. Wall,55212,cb,1B329,6148604775) Distribution: na Organization: AT&T Bell Laboratories Lines: 72 In article <16186@duke.cs.duke.edu> crm@romeo.UUCP (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. This is the same reason that the "unroll the loop" >argument won't work: if you unroll 'for(i=1;i<10000;1++)' into 10,000 >separate statements, you are not going to make friends with your >manager. Counting SLOC is reasonably *simple*, yes. But I'm not sure I understand what you be by objective. E.g., Programmers X & Y both are given the same assignment. Suppose that both write code of comparable quality and take approximately 5 days to write it, but programmer X wrote 500 source lines of code to do it in, and programmer Y does the same task in only 150 source lines of code. So, programmer X wrote more code than programmer Y, so what; big deal! The question we have to answer is "what does this imply?" That programmer X's code is somehow better? No. That programmer X is somehow more productive? Well yes, sort of, in the literal sense. Prog X's productivity was 100 SLOC/day, whereas prog Y's is only 30 SLOC/day. So obviously prog X is the better programmer, right? Again no. Maybe prog X is just a very inefficient coder. Also, there is the whole is of maintenance (often 50% or more of the entire life cycle). Whose code is easier to maintain? SLOC gives no real indication of this, but all OTHER things being equal, I'd have to say *I* would have to say regarding maintenance LESS SLOC is (usually) favorable. Unfortunately, using SLOC as a metric leads to all sorts of (apparent) paradoxes such as these. [See the book, "Programming Productivity", by Capers Jones for an execellant discussion of these and others.] For these reasons, I have a hard time swallowing the SLOC as a metric is "objective". I'll accept it, but only after you define in what sense it is objective. >Thing counting and empirical models based on previous experience are >precisely the way other fields do it; it's the way it is done in >practice in software engineering. Source lines of code has been a >useful measure BECAUSE within standards it works; empirical models based >on SLOC fit predictions nicely to production, AND turn out to correlate >strongly with every other model that is also predictive. (This really >isn't much of a surprise if you think about it.) These empirical models >of productivity seem to be what you claim is not well founded or does >not work. > Well that is ONE reason; however, I thing the main reason that is has been useful is because, as we both agree, it is SIMPLE. It involves almost no effort to count SLOC. (I'm not sure what you mean when you write "within standards it works". [See above.] To what standards are you refering. I need a little clarification here. I personally have seen only poor correlations when using SLOC to estimate remaining project effort. This is for 2 reasons: 1) poor initial estimates regarding the total # of SLOC were way out of line, 2) the assumption that the last X lines of code is just as easy to write as the first X lines of code were. (I believe that the assumption in 2) is false because a) the difficult code is often written last, and b) there is a larger integration problem with the last X lines of code than there is with the first X lines.) >And I clain [sic], and still do, that only fools think that SLOC is a simple >minded number without empirical support. I don't know if I'd call SLOC a "simple minded number without empirical support", but (for all the reasons stated above), I would say it is virtually useless. And in my book, that's about the same thing as calling it the former. I guess that makes me a fool then. Oh well, I've been called worse. :-) -- In person: Kevin W. Wall AT&T Bell Laboratories Usenet/UUCP: {att!}cblpf!kww 6200 E. Broad St. Internet: kww@cblpf.att.com Columbus, Oh. 43213 "Death is life's way of firing you!" -- Hack rumor Brought to you by Super Global Mega Corp .com