Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!ogicse!uidaho!med.cs.uidaho.edu!oman
From: oman@med.cs.uidaho.edu
Newsgroups: comp.software-eng
Subject: Re: COCOMO
Message-ID: <1991Jun20.192508.12653@groucho>
Date: 20 Jun 91 19:25:08 GMT
References: <1991Jun18.033606.1362@netcom.COM> <568@smds.UUCP> <1991Jun19.174716.6861@netcom.COM>
Sender: @groucho
Distribution: comp
Organization: University of Idaho
Lines: 20
Nntp-Posting-Host: med.cs.uidaho.edu

>As with all such metrics, the baselines should be calculated in terms of
>COMPLEXITY. How many complexities could you write per year in 1962 vs
>1991? THAT'S the critical issue, and I believe there is a wealth of
>evidence that modern languages and environments have greatly increased
>productivity when it is measured in this way. SLOC obscures the truth.

I think this is also an inappropriate way to think about productivity.
Instead of thinking in these terms, we should be looking at success in
terms of completeness and user satisfaction.  Hence, productivity is the
highest number of requirements (user needs) implemented with the least
lines of code and complexity.  Therefore, if I can meet all of my 
customer's needs with the simplest and smallest program, then I am the
most productive.  Thus, a ratio of needs/size or needs/complexity (or,
for that matter, size/needs and complexity/needs) comes to mind with the
goal of attaining an optimal ratio of 1.

-----------------------------------------------------------------------------
--   Paul W. Oman, Ph.D., C.S. Dept., Univ. of Idaho, Moscow, ID, 83843    --
--     em: oman@cs.uidaho.edu    ph: 208-885-6589    fx: 208-885-6645      --
-----------------------------------------------------------------------------