Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.software-eng Subject: Re: COCOMO Message-ID: <1991Jun19.174716.6861@netcom.COM> Date: 19 Jun 91 17:47:16 GMT References: <1991Jun18.033606.1362@netcom.COM> <568@smds.UUCP> Distribution: comp Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 25 >On the other hand I will grant you that modern software and hardware >technology does mean that you can do more in the same number of lines >of code, and that it is much easier to build large programs. Well, this wasn't my original objection, but as long as you've brought it up, this is the OTHER thing I find absurd about the COCOMO approach: the focus on SLOC. You cranked out 20 KSLOC of code in 1962. What language was it? Assembler? FORTRAN? In 1990 I cranked out 20 KSLOC of Ada, complete with tasking, genericity, exception handlers, constraint checking, etc. To achieve this same level of functionality in a 1962 language, I might well have had to write 10-100 times as many lines of code. How much assembler would you have to write to provide dynamic binding and inheritance a la C++? My guess is: considerably more than you could write in a year (ask Stroustrup!). 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. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *