On January 5, 1995, I requested discussion of the question -- How do you
evaluate program cost? The following is my promised summary of the
responses. The task wasn't difficult as there were only seven replies;
three from end-users and four from software developers/consultants. All
agreed that there is no correlation between the number of lines of code
and its cost to produce or purchase.
 
Most developers favored charging an hourly rate to develop applications.
If pressed for fixed cost, most respondents consider such things as
"number of on-line screens and reports,"  or anticipated difficulty, when
estimating the time an "average programmer" would take to produce the
code. Not surprisingly end-users talked about functionality, quality, and
savings as means of assessing the value (cost) of applications.
 
I am disturbed by the words of Wayt Gibbs a staff writer for Scientific
American who says: "The vast majority of developers -- by which I mean not
only those who write computer code, but also those who design and manage
entire systems -- still work as craftsman. They do not measure what they
do. Consequently, they can't tell you, reliably, how much their system
will cost, when it will be finished, or even whether it will work as
intended."
 
This may not be THE case, but unfortunately this brief thread didn't do
much to dispel the increasingly popular notion. My thanks to all who took
the time to respond, for your serious attempts to answer what now appears
to be a difficult question for our profession (perhaps craft is more
appropriate).
 
Take care,
Frank Alden Smith