Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!apple!voder!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Personal growth and software engineering!
Message-ID: <35077@athertn.Atherton.COM>
Date: 22 Apr 91 17:14:01 GMT
References: <1991Apr19.203033.2151@dg-rtp.dg.com> <1991Apr15.200458.11331@dg-rtp.dg.com>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 53

In article <1991Apr19.203033.2151@dg-rtp.dg.com>,
cole@farmhand.rtp.dg.com (Bill Cole) writes:

|> > 2. How do we measure productivity in rev n+1 software?  That is, we
|> > seldom deal with clean-sheet projects; we spend most of our lives refining
|> > what we did before, maybe adding features or functionality.  But we don't
|> > get to work on completely new projects for the vast majority of our
|> > professional lives.  So how do you measure productivity/defects in that
|> > environment?

(Bill quoting me:)
|> Go back to what matters to the subjective decision makers above.

>I don't understand your response.  The two don't seem to map together.

What I was trying to get at is that the way you measure productivity and
defects in a constant revision process is that you measure "things that
mattered" per unit time.  Things that mattered in a bad way measure
defects per unit time.  Things that mattered in a good way (e.g.
functionality delivered) per unit time measure productivity.

One of the problems is that "things that matter in a good way" are often
only fuzzily defined.  Moreover, two things of equal value may not
require equal effort.  That's unfortunate, and you do what you can with
such fuzzy results.  Obviously, high levels of precision are not possible
in this case--but high levels are not necessarily required.  In my
experience the differences can vary between (by analogy) a football field and a
ten yard mark.  You don't have to measure with a micrometer to find
which size you are closer to. A car-length isn't a perfect yardstick,
but it might do in
a pinch when a car is close at hand.  Similarly for metrics. 
Functionality is not one to one with lines of code, but for  similar
people doing the same sort of changes to an existing application, lines
of code may give more or less
associated with functionality delivered.    You'd be able to tell if
you had more like a football field's difference or more like a ten yard
mark difference. It would be stupid to muddle about a few percent
difference in productivity by that measure--not simply because the
association between functionality and code may not be that close, but
also because the measures of functionality are not that tight anyway.
It is as silly to argue about a few inches when using the car-length measure.

This doesn't invalidate the metric.  It qualifies it.  For all the science
and engineering background, there are many problems where we just don't
need ultimate precision to have value.  A  civil engineer might well
measure a large jobs in numbers of cement truck loads, or dump trucks of
fill, or tons of steel rods, none of them absolutely precise measures,
but each fully sufficient for charaterizing the work enough for rule
of thumb metrics.  Why should it be any different in software development?

Scott McGregor                Don't expect too much of numbers, but don't
Atherton Technology           ignore the little you do get.
mcgregor@atherton.com