Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.software-eng
Subject: Re: Identifying high quality software development efforts
Summary: some cheap shots
Message-ID: <1990Oct30.204626.8783@ico.isc.com>
Date: 30 Oct 90 20:46:26 GMT
References: <1869@shodha.enet.dec.com> <5728@stpstn.UUCP>
Distribution: na
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 39

cox@stpstn.UUCP (Brad Cox) writes about some interesting statistics.  I'd
like to dig a little below the surface--i.e., find out what these numbers
really mean.  My notes are intended as "devil's advocate" views, or "cheap
shots" if you will.  That is, they're not intended as an attack on what
Brad has said; they're just intended to provoke a little more dicussion.

> Specific examples: U.S: typical 1 to 3 errors/KSLOC, .01 to .1 for critical
> software; Japan: some companies report .008 errors/KSLOC. 

First obvious shot: KSLOC doesn't measure program size, useful content, or
anything else, to any useful level.  That is, it might account for as much
as an order of magnitude difference in error rate.  (I've seen factors of
2-4 code expansion out of people being "paid by the line" relative to what
a decent programmer would write.)

Next, how could you possibly measure maintenance programming (by which I
mean not so much repair as modification) in KSLOC?  Most programmers do NOT
spend their time writing new code; they spend it modifying existing code to
do different things.

Then, what is the relative cost of the software?  How many dollars/yen per
KSLOC?

.008 errors/KSLOC is one error in 125,000 lines.  Many average-plodding
programmers won't write that much in a lifetime.  Hmmm...

What type of code shows that error rate?

> In other words, error rates one to two *orders*of*magnitude* less
> *in*spite*of* being many years behind in software technology.

Perhaps it's not "in spite of" but "because of"!  Perhaps by the time Japan
has accumulated thirty years or so of badly re-re-re-re-worked code,
trashed out and stretched beyond its breaking point five ways, with the
original authors long in the grave and all the original design criteria
violated and/or forgotten, their error rates will be as high as ours?
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...but Meatball doesn't work that way!