Xref: utzoo comp.software-eng:2484 comp.misc:7449 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!xanth!mcnc!duke!romeo!crm From: crm@romeo.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng,comp.misc Subject: Re: Programmer productivity Message-ID: <16170@duke.cs.duke.edu> Date: 22 Nov 89 17:04:59 GMT References: <34796@regenmeister.uucp> Sender: news@duke.cs.duke.edu Reply-To: crm@romeo.UUCP (Charlie Martin) Distribution: na Organization: Duke University CS Dept.; Durham, NC Lines: 96 In article <34796@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >From article , by emuleomo@paul.rutgers.edu (Emuleomo): >> I heard that the average programmer produces 3-4 lines of *finished* >> code a day! Most places now get closer to 10 SLOC a day. > >Are there metrics to measure the productivity of electronic engineers? >No? Sure there are. >Then how about measuring the productivity of mechanical engineers? >Another blank? Nope. Happens all the time. >Another blank? Perhaps they measure the productivity of civil engineers >Perhaps they measure the productivity of civil engineers >some way? No again? Sorry, but civil engineers as well. >Perhaps a pattern can be seen here. Yes, I do think you're right: there is a pattern. It obviously isn't the one that you expect. I'm a little bit sorry to take this approach, but I think you'll find that there is some kind of way to measure the productivity, and to estimate based on that productivity, in every engineering field and many other fields as well (for example, the common rule of thumb for technical writing is one staff day per completed page of camera-ready text.) What's more, I'm only a little bit sorry because I think you have failed the back of the envelope first-principles test, which is one that every engineer ought to consider. If there *were* no way to measure, estimate, and predict the productivity of engineers, what would happen? Therer would be, for example, no way to say "we'll start designing this building on monday, and we'll expect to review the designs with the customer in 16 weeks; if that goes okay, then we'll plan for final review with the contractor in 30 weeks, and construction can start on week 40." It *is* true that many other engineering areas have difficulty making very precise estimates, or measuring progress precisely. ("Good news, dear! Today my staff engineered 0.000301 percent of the new bridge. That's up 0.000007 from yesterday!") To that extent, there is some justification in your statement, and your comparison. What does it mean to say that 90% of the system is done? (Another 90% of the work left, of course....) But to claim that other engineering fields have no measures of estimating techniques, and (by implication) that it is foolish for software engineering to look for suitable ones, is probably suitable for fertilizer after suitable composting. > >The real question here is: can you find a functional definition of >programmer productivity? I submit that you cannot. What is your claim here? That programmers produce nothing, and therefore it isn't measurable? I can offer many functional definitions under an appropriate definition of the word "functional": - number of lines of code - number of machine-level instructions - number of pages of finished product - total cost divided by number of staff days and for maintenance, - number of problem reports solved per staff day - progress of quality measures toward a goal, per staff day of effort These measures have theoretical problems (what is a line of code? a page of product?) but they have all proven useful in practice, and all have some predictive value. >Certainly, lines of >finished code fails the test of being meaningful quite thoroughly! What >is the point of trying to equate a programmer with a manufacturing robot? > What is the point of trying to measure the efforts at all? What does "meaningful" mean here? Empirically, lines of code work reasonably well in practice, although this usually requires a lot of tuning of the weighting factors; lines of code estimates and measures also correlate quite highly with other "better founded" measures, when those measures correlate with observed performance. Or is there so little of science in software engineering that it is impossible to measure its effect at all? Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)