COCOMO - appropriate for languages like Python?
Skip Montanaro
It's been many years since I've considered software cost estimation models
like COCOMO. Is COCOMO appropriate to apply to high-level languages like
Python? I believe COCOMO assumes each fully debugged source line of code
(SLOC) in any language and for any purpose costs roughly the same amount to
produce. The cost savings for languages like Python would come because you
have to write so many fewer lines of code to implement the desired
functionality.
This constant cost per SLOC assumption seems at least marginally invalid to
me. For example, writing an extension module which wraps a preexisting C
library is generally pretty straightforward (even without tools like SWIG or
Pyrex), but is pretty verbose, so COCOMO would tend to overestimate the cost
to produce such code. It also seems the clarity of a language's constructs
will make a difference. For example, in C I can write
if ((c = gets(s)) == EOF) {
...
}
while in Python, even though I have to express that concept in two lines:
s = sys.stdin.readline()
if s == "":
...
you can argue the Python code is less likely to contain a bug. Together,
the cost to create those two (fully debugged) lines of Python code may well
be less than the cost to create the one line of C code, not twice the cost
of the one line of C code, as COCOMO would estimate it.
Are there other (more modern?) cost estimation models which don't assume
cost-wise that a SLOC is a SLOC is a SLOC?
--
Skip Montanaro
sk...@pobox.com
consulting: http://manatee.mojam.com/~skip/resume.html
Robert Kuzelj
> It's been many years since I've considered software cost estimation models
> like COCOMO. Is COCOMO appropriate to apply to high-level languages like
> Python? I believe COCOMO assumes each fully debugged source line of code
> (SLOC) in any language and for any purpose costs roughly the same amount to
> produce. The cost savings for languages like Python would come because you
> have to write so many fewer lines of code to implement the desired
> functionality.
dont know about cocomo (thou i read caper jones' book bout software
estamating -
but that was sometime ago). but i am a fan of function point analysis
(fpa)
and there they have the concept of a productivity factor (dont know
the exact
term, sorry) which tells you how many function points you are able to
express with (if i remember correctly) 1K SLOC. i can remeber a table
saying that this factor was twice as high for python as with java.
i have looked on the net but could not find the exact link.
> This constant cost per SLOC assumption seems at least marginally invalid to
> me. For example, writing an extension module which wraps a preexisting C
> library is generally pretty straightforward (even without tools like SWIG or
> Pyrex), but is pretty verbose, so COCOMO would tend to overestimate the cost
> to produce such code. It also seems the clarity of a language's constructs
> will make a difference. For example, in C I can write
>
> if ((c = gets(s)) == EOF) {
> ...
> }
>
> while in Python, even though I have to express that concept in two lines:
>
> s = sys.stdin.readline()
> if s == "":
> ...
>
> you can argue the Python code is less likely to contain a bug. Together,
> the cost to create those two (fully debugged) lines of Python code may well
> be less than the cost to create the one line of C code, not twice the cost
> of the one line of C code, as COCOMO would estimate it.
>
> Are there other (more modern?) cost estimation models which don't assume
> cost-wise that a SLOC is a SLOC is a SLOC?
one of the usual misconceptions about metric-suites, of which software
estimating is one, is that they do treat everything uniformly. but
every
metrics book (and paper) advises you to tailor you metrics program to
your (that is your project) needs. so for example if your projects
consists of a lot of very dense declarative sourcefiles that will be
transformed into very verbose sourcefiles (eg. python - > c) you
are asked to measure those resulting sourcefiles differently than
sourcefiles that might be written from hand.
one very simple categorisation might be
id | description | loadfactor
--------------------------------------------
1 | completely handmade files | 1
2 | partially generated | 0.5
3 | fully generated | 0.15
etc.
so i dont belive that cocomo says a sloc a sloc is a sloc.
at least fpa doesnt do that and it predates cocomo II.
ciao robertj
Andrae Muys
> For example, in C I can write
>
> if ((c = gets(s)) == EOF) {
> ...
> }
>
> while in Python, even though I have to express that concept in two lines:
>
> s = sys.stdin.readline()
> if s == "":
> ...
>
> you can argue the Python code is less likely to contain a bug. Together,
> the cost to create those two (fully debugged) lines of Python code may well
> be less than the cost to create the one line of C code, not twice the cost
> of the one line of C code, as COCOMO would estimate it.
Of course you can argue that the Python code is definately less likely
to contain a bug, as you can reasonably argue that the C code most
definately does ;)
Hint: Do-not use gets()!!!
#include "buffer.h" /* Handles char* buffers, includes BUFFER_SIZE */
#include "list.h" /* Standard Linked List impl, used for vector
scatter gather on input */
#include <stdio.h>
#include <stdlib.h>
char *readline(FILE *in) {
List *buffers = newList();
List *currBuffer = buffers;
List *prevBuffer = NULL;
int totalLength = 0;
char *result = NULL;
char *head = NULL;
buffers->data = newBuffer(BUFFER_SIZE);
buffers->data[0] = '\0';
while (fgets(currBuffer->data, BUFFER_SIZE, in) != NULL) {
totalLength += strlen(currBuffer->data);
if (currBuffer->data[strlen(currBuffer->data) - 1] == '\n') {
break;
}
currBuffer->next = newList();
currBuffer = currBuffer->next;
currBuffer->data = newBuffer(BUFFER_SIZE);
}
if (buffers->data[0] == '\0') {
return NULL;
}
result = newBuffer(totalLength + 1);
head = result;
currBuffer = buffers;
while (currBuffer != NULL) {
strcpy(head, currBuffer->data);
head = head + strlen(currBuffer->data);
prevBuffer = currBuffer;
currBuffer = currBuffer->next;
delBuffer(prevBuffer->data);
delList(prevBuffer);
}
return result;
}
if ((s = readline(stdin)) == NULL) {
...
}
So the actual C code equivalent is ~30 lines (I personally prefer to
include whitespace) compared to 2. So a 15:1 cost factor is suddenly
more reasonable. Note I haven't even attempted to compile the
readline() function, and it assumes the existence of suitable
buffer/list libraries (and accompaning logging/error functionality,
readline() will be longer if error-recovery is required).
However the really important thing to notice is that the language has
very little to do with the number of lines. In fact for this trivial
example C and python are equivelent in almost all meaningful measures
once you have access to a decent IO library!
This agrees with my personal experience and annocdotal evidence, that
the libraries and frameworks used are at least as important as the
language itself when determining programmer productivity. Hence the
signifigant impact of Python's 'Batteries-included' approach (and I
personally believe a signifigant part of the continued success of Perl
courtesy of CPAN).
Andrae Muys
Skip Montanaro
Andrae> Hint: Do-not use gets()!!!
Thanks for the elementary C security tutorial, but it really wasn't
necessary. I wanted to use gets() because it was semantically the closest
to file objects' readline() method (read a line from sys.stdin in this
case). Yes, I could have used fgets(s, 80, stdin) or something similar.
That wasn't the point of the post. I was asking about COCOMO.
Jonathan Hogg
mailman.1026153791...@python.org, "Skip Montanaro"
<sk...@pobox.com> wrote:
> Andrae> Hint: Do-not use gets()!!!
>
> Thanks for the elementary C security tutorial, but it really wasn't
> necessary. I wanted to use gets() because it was semantically the closest
> to file objects' readline() method (read a line from sys.stdin in this
> case). Yes, I could have used fgets(s, 80, stdin) or something similar.
> That wasn't the point of the post. I was asking about COCOMO.
I thought the point was very valid. COCOMO is about fully-debugged lines of
code. Andrae pointed out that your comparison was false because the lines of
C code were clearly not "fully-debugged" and thus not comparable.
Adding in the code necessary to implement comparable functionality results
in a 30x increase in lines of code - and this doesn't even include any
exception processing necessary to raise an appropriate error condition if
the file isn't open or some other I/O error occurs.
Comparing bits of code in-the-small almost never yields anything useful.
COCOMO follows out of the ability of the brain to process and manipulate
information. One can always write very sparse or very dense lines of code
that break the model, but in-the-large programmers do not normally do that.
They tend to write code in lines that fit easily in their head and, because
of this, one line of code is pretty much comparable to another.
Jonathan
Peter Hansen
>
> On 8/7/2002 19:42, in article
> mailman.1026153791...@python.org, "Skip Montanaro"
> <sk...@pobox.com> wrote:
>
> > Andrae> Hint: Do-not use gets()!!!
> >
> > Thanks for the elementary C security tutorial, but it really wasn't
> > necessary. I wanted to use gets() because it was semantically the closest
> > to file objects' readline() method (read a line from sys.stdin in this
> > case). Yes, I could have used fgets(s, 80, stdin) or something similar.
> > That wasn't the point of the post. I was asking about COCOMO.
>
> I thought the point was very valid. COCOMO is about fully-debugged lines of
> code. Andrae pointed out that your comparison was false because the lines of
> C code were clearly not "fully-debugged" and thus not comparable.
There's no such thing as fully debugged. There is, however, "adequately
debugged" (though how one gets there I'm not sure :-), and it's quite
possible that Skip's one-liner with gets() was entirely suitable for
the intended application. It's not *always* necessary to write highly
robust code, and in that light it's quite possible the comparison is
still entirely valid.
-Peter
James J. Besemer
Skip Montanaro wrote:
It's been many years since I've considered software cost estimation models
like COCOMO. Is COCOMO appropriate to apply to high-level languages like
Python?
I believe COCOMO assumes each fully debugged source line of code
(SLOC) in any language and for any purpose costs roughly the same amount to
produce.
The cost savings for languages like Python would come because you
have to write so many fewer lines of code to implement the desired
functionality.
IIRC, COCOMO has a "knob" for how high or low level the programming language in use happens to be.
Are there other (more modern?) cost estimation models which don't assume
cost-wise that a SLOC is a SLOC is a SLOC?
COCOMO does NOT make the assumption about SLOC cost that you seem to believe. For COCOMO to work AT ALL it needs to be calibrated with historical data about your own shop (e.g., historical average cost/LOC). Without the historical data then the model will be unable to predict anything meaningful about your performance.
I'm sure there are other, much simpler methods that work OK.
Actually, COCOMO is somewhat Baroque, in that it originally attempted to take into account all sorts of major and minor factors affecting in software development. After applying COCOMO to A Lot of projects, Bohem discovered that a small number of factors made most of the difference:
The biggest productivity factor was quality of people. There is like a 1000:1 range of productivity between the top and bottom performers in large organizations. This generally swamps everything else, including choice of language, or personnel costs (the 1000x guy does not cost 1000x as much as the bottom performer).I forget how the others factors ranked but IIRC, choice of language (high or low) was fairly low in the overall ranking.The second biggest factor is overall size of the project. That is, all other things equal, the cost per LOC is NOT constant, but it is higher on a large project and smaller on a small project. Furthermore, it appears to grow exponentially on overall project size, swamping all other factors on very large projects.
From a management standpoint, your strategy should be to always strive to hire the very best people and to break projects into moderate sized, easily handled chunks.
From a schedule estimation standpoint, LOC (however you choose to count them) appears to be a pretty good estimator to use for a fixed staff and fixed project sizes. How the prediction varies as you change staff or project sizes is something you'll have to measure or guess at yourself. At least COCOMO research gives you some idea how the curves are shaped.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:j...@cascade-sys.com
Andrae Muys
> From a management standpoint, your strategy should be to always strive to hire
> the very best people and to break projects into moderate sized, easily handled
> chunks.
>
> From a schedule estimation standpoint, LOC (however you choose to count them)
> appears to be a pretty good estimator to use for a fixed staff and fixed project
> sizes. How the prediction varies as you change staff or project sizes is
> something you'll have to measure or guess at yourself. At least COCOMO research
> gives you some idea how the curves are shaped.
>
Do you have any references where I could follow up on this myself?
Andrae
James J. Besemer
Andrae Muys wrote:
The quoted exerpts above are merely my humble opinions, based on many many years of software development and software
development management.
If you google.search( COCOMO ) you get lots of references to past and ongoing work.
If you amazon.books.search( COCOMO ) I see there's now a COCOMO II.
This looks like a substantial update to Boehm's seminal Blue book on Software Engineering Economics.
Either of the above are good as any starting point.
Mike Brenner
> From a schedule estimation standpoint, LOC (however you choose to count them) appears to be a pretty good estimator to use for a fixed staff and fixed
project sizes. How the prediction varies as you change staff or project sizes is something you'll have to measure or guess at yourself.
IMO, the following measurements apply to most Python efforts more than lines of code:
- Most software has achieved the status of "maintenance" rather than "development". Thus, millions of lines of code might require, say, a one-line change. Some of those one-line changes take a month of research and testing, while others take a few seconds. The lines of code changed (and the lines of code in the whole project) only correlate to new code, not to code under maintenance.
- Software Maintenance time primarily increases as backlog increases (e.g. programmer overtime which the company intends to not pay, other work awaiting action, inadequate functional testing, deferred regression testing which detects reappearance of prior bugs, incomplete impact analysis of past and present changes, incorrect documentation, and the age of parallel development paths). For example, parallel development paths that last more than a few days (fractured baselines) start to take on lives of their own, and become more expensive to merge into a single "golden" baseline as they age.
- Software Maintenance time decreases as the technology factor (the part of the COCOMO model that applies to software maintenance rather than to new development) increase. Thus, to save time, get better tools for: comparison, visualization, cross-referencing, text pattern search, automatic testing, slicing, and other tools to assist in determining the impact of changes. Also, use an interpreted language like Python with good debugging, tracing, and other tools. Measure the number of seconds it takes to find the line of code that caused a problem (something that gets harder when you add wxWindows, threads, servlets, graphics, COM objects, operating system calls, web services, soaps, and additional levels of interpretation to the software).
- Software Maintenance time increases with the number of data integrity problems possible in the languages and tools used (coding bugs, data design flaws, data flaws, network design flaws, rifts, and sabotage). Coding bugs include off-by-one errors, aliasing, global variables, hanging pointers, out-of-range errors, missing actions, extra actions, global typing violations (even in interpreted languages), and memory leakage. Data design flaws include failure to trigger an action (e.g. busting a referential integrity constraint), implementing a many-to-many relationship inefficiently, mismatching keys, inappropriate level of normalization, performing a wrong action, or incomplete design. Data flaws include conversion round-offs or other loss of precision, incorrect origin or units of measure, inaccurate numbers, inappropriate null data, obsolete data, out of range errors, two-digit years, and local type mismatches. Network design flaws include bandwidth too low (errors or nois!
e), bottlenecks, inadequate error detection/notification/correction, speed mismatch, missing packets, power failures, race conditions such as deadlocks, insufficient redundancy, loss of resolution, simultaneous modifications, and slow response time. Rifts are another name for the backlogs above which were called out separately because of their large effect on time. Sabotage (tampering with the data, trojan horses, viruses, authentication where none is needed, weak authentication where authentication is actually needed, worms, failure of CM to preserve the parts, management destroying service requests which were completed or cancelling to remove the evidence, and lack of backups).
- Software Maintenance time positively correlates to the amount of time that maintenance organization last maintained that type of code (after subtracting the time it takes to open up the configuration, which relates to how long since a project last opened that code).
- Software Maintenance time negatively correlates with syntactic standards. For example, a rule like "indent each level 3 spaces" slows down software maintenance and development in two ways. First, humans (like programmers, reviewers, and quality assurance auditors) will tend to spend time enforcing and carrying out such a rule, because of their ego-needs for control; people should only impose such a rule by providing a tool to enforce the rule automatically. Second, such rules limit the visualization possibilities -- for example, someone might discover a bug more quickly by viewing the code with several different indentations.
- When management decides to use a metric, and the programmers become aware of that metric, then the programmers take whatever action required to make that metric reach 100%. For example, if management pays the programmers by the line of code, the lines of code will increase.
- When management (personal, government, corporate, academic) requests non-applicable metrics like lines of code (a metric which makes sense only at development time) or McCabe Cyclomatic Complexity (a metric which makes sense only at testing time since it counts test paths and dings programmers for good stuff like nested SWITCH/CASE statements and BREAKs) to describe maintenance effort, consider get rid of that entire levelly management.
- Without an accepted standard definition of "lines of code", one cannot know whether to count every line in every IMPORTed module, or just those the INVOKED lines, or just those lines that do the invoking. For example, do we count every line in the python runtime module STRING.PY or just the lines in STRING.PY that our modules call, or just the lines in our module that call STRING.PY? These different counting strategies differ by orders of magnitude.
Mike Brenner
James J. Besemer
"Delaney, Timothy" wrote:
> How does it deal with negative LOC? There are many cases where I consider
> myself much more productive if I can *reduce* the code base.
I don't know.
But of course I'll hazard a guess. ;o)
I imagine the cases where adding a feature or fixing a bug actually makes the
overall code smaller are infrequent enough to be ignored. That is, in the
overall scope of the project, the code grows by G and shrinks by S and S is
much smaller than G. Again, the models apply (if at all) to projects overall
and not to individual programmer tasks.
Another angle here: I too can think of cases where I make the code "better"
by making it smaller. E.g., replacing some hairy decision tree with a table
driven approach. Or some predecessor's gunked up spaghetti code with
something clean and readable. Often I am lucky in that I get paid to perform
subtle optimizations like this that don't have a direct bearing on the
product's overall functionality. Question is: is my productivity in this
case positive or negative? If I "improve" something that does not materially
affect the user, it could be argued that this is in fact negative
productivity. After all, the client is paying something for nothing. At
best, if you argue that the improved code reduces long-term maint costs, then
the client is trading off a direct up-front cost for a long term benefit of
dubious value.
There are all sorts of different ways to view "programmer productivity."
Regards
--jb
p.s. Didja get that winreg stuff to work?
James J. Besemer
Mike Brenner wrote:
> > JB wrote:
> > From a schedule estimation standpoint, LOC (however you choose to count > them) appears to be a pretty good estimator to use for a fixed staff and fixed
> > project sizes. How the prediction varies as you change staff or project sizes is > something you'll have to measure or guess at yourself.
>
> IMO, the following measurements apply to most Python efforts more than lines of code:
The issues you raise are valid, though I think most can be restated in terms of a LOC productivity factor.
> - Most software has achieved the status of "maintenance" rather than "development". Thus, millions of lines of code might require, say, a one-line change. Some of those one-line changes take a month of research and testing, while others take a few seconds. The lines of code changed (and the lines of code in the whole project) only correlate to new code, not to code under maintenance.
To my mind, this is simply saying the average cost per new LOC is rather high in these circumstances and also the standard deviation also is high. IIRC, COCOMO has a way to take this into account.
> - Software Maintenance time primarily increases as backlog increases (e.g. programmer overtime which the company intends to not pay, other work awaiting action, inadequate functional testing, deferred regression testing which detects reappearance of prior bugs, incomplete impact analysis of past and present changes, incorrect documentation, and the age of parallel development paths). For example, parallel development paths that last more than a few days (fractured baselines) start to take on lives of their own, and become more expensive to merge into a single "golden" baseline as they age.
Increased backlog = increased project size. Per COCOMO, this => increased cost per new LOC or (more likely) decreased LOC per unit cost.
However, IIRC, COCOMO does not have a parameter to calibrate for this particular criterion.
Ha! Reminds me of one place I worked. The company lumped telephone tech support and software QA into a single group. QA schedules were pretty much fixed and when the phone rang it had to be answered, so this created a feedback loop in the ongoing software quality -- if it started to dip, phone calls went up, causing it to spiral further downward, due to even less QA resource.
> - Software Maintenance time decreases as the technology factor (the part of the COCOMO model that applies to software maintenance rather than to new development) increase. Thus, to save time, get better tools for:
Agreed. Per COCOMO, better tools => lower cost per new LOC.
> - Software Maintenance time increases with the number of data integrity problems possible in the languages and tools used (coding bugs, data design flaws, data flaws, network design flaws, rifts, and sabotage).
tools, problem domain complexity => increased cost per new LOC
> - Software Maintenance time positively correlates to the amount of time that maintenance organization last maintained that type of code (after subtracting the time it takes to open up the configuration, which relates to how long since a project last opened that code).
staff experience, staff domain experience => lower cost per new LOC
> - Software Maintenance time negatively correlates with syntactic standards.
"Good" standards can help even without a tool, e.g., by improving readability. "Bad" standards hurt no matter what. Good vs. bad is somewhat subjective.
Whether good is worth the cost is debatable, though i've seen so many horror stories in code formats that I suspect some minimum standard always is in order. So I'll say "good" standards => lower cost per new LOC but the difference may be marginal.
If you're going to enforce a standard, having a pretty print tool is best.
> For example, a rule like "indent each level 3 spaces" slows down software maintenance and development in two ways.
I agree. This is an example from one of the worst standards I ever encountered.
> - When management decides to use a metric, and the programmers become aware of that metric, then the programmers take whatever action required to make that metric reach 100%. For example, if management pays the programmers by the line of code, the lines of code will increase.
Having all the underlying metrics lying around begs the issue of why not use them to judge programmer performance? Some organizations have tried to do this and, yes, programmers immediately respond by inflating the metrics.
Most promoters of cost modeling strongly recommend against doing this, precisely because it interferes with and distorts the result of future predictions.
Furthermore, while measuring lines of code may be useful in predicting future lines of code, this is absolutely no way of measuring a person's contribution to the organization. Also the metrics work because they measure and predict gross, aggregate performance of a group on a project, not details about individuals.
The primary intended usage of models such as COCOMO is to predict future project costs. That is, you calibrate the model with existing data in order that your future predictions about future projects will be more accurate. In order for this to work you generally need to assure programmers that the metrics specifically will NOT be used for performance measurement. The theory relies on people NOT changing their way of doing things and you generally need buy-in and full cooperation from the developers for it to work. Thus you need to be open and honest and consistent about how the metrics will be used and how they will not be used.
Your concern here is valid but nobody I know of advocates abusing metrics this way.
> - When management (personal, government, corporate, academic) requests non-applicable metrics like lines of code (a metric which makes sense only at development time) or McCabe Cyclomatic Complexity (a metric which makes sense only at testing time since it counts test paths and dings programmers for good stuff like nested SWITCH/CASE statements and BREAKs) to describe maintenance effort, consider get rid of that entire levelly management.
I rather think LOC is a valid metric in all circumstances (although I agree it may be less reliable and thus less useful in some extreme cases).
Cyclomatic Complexity metric was devised to abstract the code's underlying complexity away from purely lexical issues such as LOC which are more easily perverted by the developer. To my knowledge, none of the more complex metrics have shown themselves to be any better than simply counting LOC. And they're much harder to measure. So, IMHO, anything more complex than LOC is not worth the bother.
> - Without an accepted standard definition of "lines of code", one cannot know whether to count every line in every IMPORTed module, or just those the INVOKED lines, or just those lines that do the invoking. For example, do we count every line in the python runtime module STRING.PY or just the lines in STRING.PY that our modules call, or just the lines in our module that call STRING.PY? These different counting strategies differ by orders of magnitude.
I personally would count the import statements but not any of the imported lines. My view is that you have a list of modules written by a programmer and Linux' "wc" command tells you the lines of code. You don't get credit for an imported module unless you write it. More generally, I'd envision a CVS system that tracks lines changed, as in larger projects, different people ultimately work on the same modules. What about comments and blank lines? I say count 'em. Comments certainly CAN be as valuable as code. I also think blank lines as a form of code paragraphing are very important. If it was being abused, I might count multiple consecutive blank lines as a single one.
While it is true that the definition of "LOC" can vary widely it is only important that you use the same definition across the domain of projects you wish to analyze (typically your own company or organization). Different definitions can produce consistent results so long as the definition is consistently applied to all the data.
Of course, if you're trying to compare your projects to Boehm's or somebody else's, then it's probably apples and oranges. Even if you count LOC precisely the same way as the other org, numerous other variations are likely to account for an even bigger differences. The interesting thing about Boehm's work is that he has data for so many projects that the results likely do apply to your project in a more general level, in that the shapes of the curves likely will be similar, even if baseline and rates may vary.
How do *I* use all this? Really.
First off, I'm certainly not a big COCOMO fan. I've never actually used the full model for anything and don't rely on metrics or modeling much in real life. I read the book and it had some interesting insights. Some of the most important results from Boehm are the general results which pretty much apply to all projects. E.g., the vital importance of hiring only the best people and keeping project steps manageable (overall cost increases extra-lineraly with size). Boehm's not the first to say this but what's interesting is he says ALL the other factors are decidedly less important.
Beyond that what I take away from this entire subject is that LOC is one easily computed, moderately useful, crude measurement of programmer productivity. It's better than nothing and I am unconvinced that anything more complicated is at all worth the extra effort. I usually use LOC to double-check my own progress. Typically a project seems to be taking longer than it should, I'll do a WC, and sure enough, it's working out to be like twice or 3X code than I expected. It's on occasion proved helpful with clients. E.g., I had a client complain about my bills and I was able to show that my company's contribution to his project was approximately twice the LOC as were in the original application; thus we were actually a bargain, since he paid many times as much to get that first 1/3. Counting lines is not the solution to all problems but it is yet another tool that has proven to be of some use to me on some occasions.
Regards
--jb
Delaney, Timothy
>
> To my mind, this is simply saying the average cost per new
> LOC is rather high in these circumstances and also the
> standard deviation also is high. IIRC, COCOMO has a way to
> take this into account.
How does it deal with negative LOC? There are many cases where I consider
myself much more productive if I can *reduce* the code base.
Tim Delaney