UH2@PSUVM.BITNET (Lee Sailer) (02/25/88)
The most recent article of CACM has a good article on a new software metric called NPATH that addresses exactly the issues that were discussed here a few netweeks ago. Also, I got a demo package of a program that computes several well-known metrics for C, M2, Pascal, Fortran, and (rsn) COBOL and Ada. Though I've only fooled with it a few minutes, it seems to do just what you'd want. (It reads your mind a outputs corrct code 8-). The compaany is SET Labs, in Portland Or, 503-289-4758. It runs on msdos and (rsn) Macintosh. lee
kww@cbnews.ATT.COM (Kevin W. Wall) (11/23/89)
Before we are all at each other's throats arguing how programmer productivity should be measured, I suggest you all check out the book "Programming Productivity" by T. Capers Jones (1987 ??). It points out the many apparent paradoxes of using SLOC as a metric for measuring productivity -- most of which are very non-intuititve. It is the ONLY book that I've seen on software metrics which I think contains the STRAIGHT SCOOP (i.e., no hype) on this crucial area. I highly recommend it. Now getting back to SLOC, let's face it -- the general reasons that SLOC still being used as a measure of programmer productivity are: 1) management demands some quantitative measurement (& rightfully so). 2) SLOC is a very easy thing to measure. 3) other possible software metrics (e.g., Halstead's, McCabe's, function points, etc.) are either difficult to calculate, or difficult to interpret, or both. I assume that most readers of this newsgroup are well aware of the shortcomings of using SLOC as an accurrate software metric. (If not, see T. Caper Jones' book, mentioned above.) Instead of pointing out are the things that are wrong with SLOC, how about hearing some success stories using some other software metric (e.g., McCabe's complexity metric, etc.). Also (surprise, surprise), not all of software development consists of programming. That is just the implementation phase. What metrics do you use (or "should be used") for measuring productivity of those involved in design, testing, requirements, etc.? -- 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
crm@romeo.cs.duke.edu (Charlie Martin) (11/25/89)
In article <11690@cbnews.ATT.COM> kww@cbnews.ATT.COM (Kevin W. Wall,55212,cb,1B329,6148604775) writes: >.... >I assume that most readers of this newsgroup are well aware of the shortcomings >of using SLOC as an accurrate software metric. (If not, see T. Caper Jones' >book, mentioned above.) > >Instead of pointing out are the things that are wrong with SLOC, how about >hearing some success stories using some other software metric (e.g., McCabe's >complexity metric, etc.). > The funny thing about the other measures (e.g. McCabe and Halsted) is that they don't seem to be a lot more predictive than weighted SLOC models like COCOMO. Also, just like SLOC, they can be confounded by pathological programs: Elliot Soloway has a perfectly hilarious comparison of two programs with the same McCabe complexity, but where one is instantly and obviously much harder to code or maintain than the other. (This was done by choosing odd names, odd loop bounds and array indicises, that sort of thing. Another example of a way to confound McCabe or Halstead is programming with variable names like O0OO0.) >Also (surprise, surprise), not all of software development consists of >programming. That is just the implementation phase. What metrics do you >use (or "should be used") for measuring productivity of those involved in >design, testing, requirements, etc.? There is plenty of work to be done in this, no question. Common assumption is that, given the time for the whole thing guessed by SLOC, you can then guess the time for a phase by taking a proportionate slice of the total for that phase. But those time to complete SLOC rules of thumb, like 3-4 SLOC per staff day, represent total time to complete, not just implementation. Another good book on software engineering metrics is the Conte, Dunsmore and Shen book _Software Engineering Metrics and Models_. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
gt@hpfcmgw.HP.COM (George Tatge) (11/28/89)
From a business perspective there is only one meaningful measure of productivity for programmers or EE's or ME's or whatever. Unfortunately, it is a measure that includes a huge number of other factors such as marketing, sales, support, etc. That measure is return on investment (ROI). How much did it cost to write this code; how much did we make from it? From other perspectives (eg. social benefits, advancement of the human race, etc.) it doesn't really matter if we measure productivity. Results of such long term benefits are all that matter, the cost is insignificant. gt