Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!farmhand!cole
From: cole@farmhand.rtp.dg.com (Bill Cole)
Newsgroups: comp.software-eng
Subject: Re: Personal growth and software engineering!
Message-ID: <1991Apr15.200458.11331@dg-rtp.dg.com>
Date: 15 Apr 91 20:04:58 GMT
References: <JGAUTIER.91Apr8184934@vangogh.ads.com> <35017@athertn.Atherton.COM>
Sender: cole@farmhand (Bill Cole)
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 47

Scott McGregor writes:
|> 
|> (Bunch o' stuff deleted)
|> 
|> In conclusion, I think that the  problem with metrics such as the ones
|> Jorge gives is not in their derivation, but in ourselves.  Mostly when
|> people see numbers like this they are annoyed because they don't give
|> specific answers about what to do to improve your process.  That is
|> correct.  But they do provide benefit in that they can suggest specific
|> questions.  Unfortunately, this is where one problem in ourselves lies.
|> Mostly we don't really want more questions.  Mostly we don't enjoy the
|> painstaking observation and study necessary to answer these questions.
|> We might well prefer to get on with fun activities like coding.
|> We want answers, not more questions.  Since metrics like these raise more
|> questions, we don't want them.  In fact, we don't want them so strongly,
|> that we ignore useful information in them that would have to be derived.
|> 1000 lines in 3 months is hard to understand what it means 2 lines / hour
|> is more understandable, but it takes some work to get from the former to
|> the latter.  We don't like these metrics puzzlers, so  we don't bother
|> to do the work to really understand the number. Instead we allow
|> ourselves to get more numb about these metrics (number and number about
|> more numbers? :-)
|> 

1. What's a defect?  Is it a mis-spelling?  An annoying placement of a 
message?  A mis-mapped message?  Is a corruption of a database?  Is it
a crashed system?  The defect-is-a-defect-is-a-defect mentality doesn't
reflect the way we view products -- software or not.

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?

3. Who cares what the lines-per-timeframe is? or the defects-per-line
if the software is delivered per the agreed-upon schedule and with the
agreed-upon level of quality (as measured by the known bug count of various
levels of problems)?  Notice that the assumption here is that the schedule
was 'reasonable' and that the quality level was 'rational' -- and that the
folks doing the developing agreed to all this.

We can measure and 'quantify' all day, but the bottom line is customer
satisfaction.  And the perception of quality.

I'm alone in the room, so the opinions are my own,
/Bill