Standard Cost of Development Per Line of Code ???????
Mark Reeves
What is the generally accepted cost of COBOL development per line of
code? I know the cost could vary greatly depending on a number of
factors, but isn't there a generally accepted number used within the
industry as a 'benchmark'?
Thanks
Mark Reeves
ree...@neosoft.com
Don Scott
On 21 Oct 1997 17:28:12 GMT, "Judson D. McClendon"
<judm...@mindspring.com> wrote:
>Mark Reeves <ree...@neosoft.com> wrote:
>> What is the generally accepted cost of COBOL development per line of
>> code? I know the cost could vary greatly depending on a number of
>> factors, but isn't there a generally accepted number used within the
>> industry as a 'benchmark'?
>
>A friend who programs for NASA said their standard is $30/line. The
>complete systems I design and program generally cost my clients between
>$0.50/line and $1.00/line, start to finish. I charge $95/hr for small
>projects, $75/hr for long term projects. I don't know what the 'industry
>standard' is, but would be interested in hearing.
If you are charging .50 to $1.00 per line at $95/hr, that would
calculate to 700 to 1500 fully developed (code, test, implemented)
lines of COBOL per day. That is WAY over the industry standard, isn't
it?
Judson D. McClendon
Mark Reeves <ree...@neosoft.com> wrote:
> What is the generally accepted cost of COBOL development per line of
> code? I know the cost could vary greatly depending on a number of
> factors, but isn't there a generally accepted number used within the
> industry as a 'benchmark'?
A friend who programs for NASA said their standard is $30/line. The
complete systems I design and program generally cost my clients between
$0.50/line and $1.00/line, start to finish. I charge $95/hr for small
projects, $75/hr for long term projects. I don't know what the 'industry
standard' is, but would be interested in hearing.
--
Judson McClendon This is a faithful saying and worthy of all
Sun Valley Systems acceptance, that Christ Jesus came into the
judm...@mindspring.com world to save sinners (1 Timothy 1:15)
(please remove zzz from email id to respond)
Judson D. McClendon
> >> What is the generally accepted cost of COBOL development per line of
> >> code? I know the cost could vary greatly depending on a number of
> >> factors, but isn't there a generally accepted number used within the
> >> industry as a 'benchmark'?
> >
> >A friend who programs for NASA said their standard is $30/line. The
> >complete systems I design and program generally cost my clients between
> >$0.50/line and $1.00/line, start to finish. I charge $95/hr for small
> >projects, $75/hr for long term projects. I don't know what the
'industry
> >standard' is, but would be interested in hearing.
>
> calculate to 700 to 1500 fully developed (code, test, implemented)
> lines of COBOL per day. That is WAY over the industry standard, isn't
> it?
I don't know, Don, that's why I'm interested. My current primary project
is particularly complex and slow to code; there are more exceptions than
rules. I designed the system and am responsible for writing the online
portion. The in-house MIS staff is writing the reports and batch programs.
I've been working on it for about 10 months, billed about $104k, and
written about 110 screens with 107k lines of code. No code was written
during design, of course, but I'm writing code most of the time now. When
the dust clears, there will be roughly 200 online screens with about 200k
lines of code, at a total cost of about $160k-$180k.
In my experience, high productivity is something you have to work hard to
achieve. I do work hard at maximizing productivity, and over some 29 years
have developed many useful methods. I have standard ways of doing things,
and write all my utility routines so they are generic and easily reusable.
I have developed a data dictionary facility for online programs which
supports online help and field validation, and using it is so
straightforward that I use a program to generate the code from a list of
field names. This is very fast and virtually error free, since I copy the
field names from the database definition using my text editor. I have
written programs to scan my COBOL source files and flag certain kinds of
errors which the compiler won't catch and which are hard to spot visually.
I also take off when I don't feel well, unless pressed by deadline, because
I don't like to charge a client for poorly productive time. This improves
my lines/hr ratio some. Another factor is that I usually work alone.
Adding more people greatly increases the amount of time you have to spend
on coordination and such. This limits the size of projects I can accept,
and occasionally I subcontract.
This is a little off subject, but talking about productivity reminds me of
work goals and motivation. I am concerned that the computer industry, like
the rest of society, seems to have lost the motivation for excellence. My
primary work motivation, even more than quantity, is quality. I always
tell a new client "You may find somebody else who can do the work cheaper
or faster or better than me. But my commitment to you is that, when you
get a system from Jud McClendon, you get the very best that Jud McClendon
can produce." After the first few weeks of getting the final bugs out of a
newly installed system, I usually only hear from my clients when they want
something new. Nine years ago I wrote a pretty complex multi-user (Novell)
PC inventory system for a client; over 100k lines of COBOL, cost about
$50k. The company is absolutely dependent on the system. If it went down
for a week, they would probably be out of business. I've had to fix maybe
a dozen program bugs since the first few months, and they have never been
down even a day from a problem with the inventory system. A very few times
I have had clients who wanted something quicker than I could work it into
my schedule, and hired someone else. As it turns out, this is the best
thing that can happen to me, because they will almost certainly get some
yahoo who is only interested in the money, and could care less about
quality. Every client came back afterwards, and now they will wait on me
for as long as it takes. People will pay well for excellence again and
again, and like it. But they don't like to pay any price for an
unreliable, poorly designed system, even once. Excellence is not about
being clever, or amazing yourself with your own brilliance. Excellence is
about being methodical and thorough, putting your client's interests ahead
of your own, and working hard to make it right.
Judson D. McClendon
Ken Foskey <kfo...@tig.com.au> wrote:
> Mark Reeves <ree...@neosoft.com> wrote:
> >What is the generally accepted cost of COBOL development per line of
> >code? I know the cost could vary greatly depending on a number of
> >factors, but isn't there a generally accepted number used within the
> >industry as a 'benchmark'?
>
>
> 500 well crafted lines of code are worth more than 2,000 badly crafted
> lines of code. Placing a $ value on KLOC would only make bad coders
> appear better. Think first and code later does not pay a per line
> quota.
Surprisingly, the statistics I have seen show that there is a close
correlation between programmer quality and output quantity. I've seen
figures showing as much as 25 times more productivity in the best
programmers vs. the worst programmers. I can certainly see a given
individual getting sloppy to maintain a high volume output when there is a
profit motive. Do companies actually reward programmers in some way using
this criteria?
Ken Foskey
On Tue, 21 Oct 1997 09:41:34 +0100, Mark Reeves <ree...@neosoft.com>
wrote:
>What is the generally accepted cost of COBOL development per line of
>code? I know the cost could vary greatly depending on a number of
>factors, but isn't there a generally accepted number used within the
>industry as a 'benchmark'?
>
In My (Not So) Humble Opinion. /begin gripe
500 well crafted lines of code are worth more than 2,000 badly crafted
lines of code. Placing a $ value on KLOC would only make bad coders
appear better. Think first and code later does not pay a per line
quota.
/end gripe
Wayne L. Beavers
> >Mark Reeves <ree...@neosoft.com> wrote:
> >> What is the generally accepted cost of COBOL development per line of
> >> code? I know the cost could vary greatly depending on a number of
> >> factors, but isn't there a generally accepted number used within the
> >> industry as a 'benchmark'?
> >
For many years I kept hearing that a good programmer produced 10 lines
of documented, debugged code per day, independent of the chosen
language. This makes COBOL, or any high level language, a better choice
then assembler because a single line of COBOL can do so much more useful
work than a single line of assembler. I suppose that this is also the
reasoning behind so many 4GL languages.
I never believed the 10 lines per day. I actually felt insulted that
someone would think that 10 lines per day was all I could do. So I
decided to measure my own productivity one time.
I was designing, coding and testing an ISPF dialog application in
assembler (I know this is a COBOL group). At the end of each day I
counted the number of 80 byte records in the source file. It was not a
very difficult project. I spent a couple of days laying out the module
flow and basic program logic. Then I started to code.
I was cranking out 100 to 200 lines of unit tested code per day. I
thought that 100 was rather low, but that was what I was measuring. At
least is was a lot better than the "average" 10 lines of code per day.
By the time I had all of the modules coded and unit testing was
completed, I had managed to remain somewhere in the 100 to 200 lines per
day range.
Then I started to do system testing. This being an ISPF dialog I tested
all of edit rules for every field. I carefully tested boundary
conditions and invalid data values. I tested relationships between
fields. I tested record not found.
It was amazing to watch the lines of code count. During system testing I
was only writing about 20 lines of code per day. Things like 20 bugs of
one line each or 10 bugs of two lines each. However, changing a broken
line of code does nothing to the total line count. So the days keep
incrementing and the total lines of code stays the same. It really
damages the average lines per day count.
During system testing I also took some time to improve the documentation
(comments) within the program. I would take the listings home in a
binder and sit back in my favorite chair and play editor with my red
pen. The next day I would key it all in. I firmly believe that an
excellent line of comment is worth a line of code.
So when it was all done and packaged up I was able to average 20 lines
of code and comments per day.
Now, if I didn't have to go to the weekly department meeting and the
monthly division meeting and answer the phone etc. ...
But then there was the project 3 weeks ago where I cranked out 1200
lines of debugged code with comments in 2 weeks. That's 120 lines of
code per day, but I also worked 12 hours per day. Maybe my productivity
improved 10 to 1 in the last few years?
--
Wayne L. Beavers mailto:Wayne_...@Beyond-Software.com
Beyond Software, Inc. http://www.beyond-software.com
"Transforming Legacy Applications"
G Moore
>> >Mark Reeves <ree...@neosoft.com> wrote:
>> >> What is the generally accepted cost of COBOL development per line of
>> >> code? I know the cost could vary greatly depending on a number of
>> >> factors, but isn't there a generally accepted number used within the
>> >> industry as a 'benchmark'?
when i was younger, i used to program alot. unfortunately it was in
basic, which made me have to remeber every variable. cobol is a little
different in that you can declare many sections of the program. I can
write about 100 bad lines of code a day, or 30-40 good ones a day, in
any of the languages I have studied, providing the project is laid out
before me. designing, however, takes away alot of time, as does
debugging anothers code. if you want high productivity, the best thing
to do, instead of hiring the best programmers, is use the best
programming language. so far, i have found that maintanence eats up
alot of time. so does learning a new function. if you want alot of
compact code, you have to hire people who not only know the language,
but who make use of the functions. In C, these functions would be
strdup instead of strcpy and calloc and strlen. In Cobol, it would be
using (:) scaling factors. also, commented code is a primary goal. I
can write about 1 school type project a day (as opposed to the alotted
two weeks), but the style is very bad. these projects generally have
everything well thought out beforehand, as opposed to real life.
in my real-life experience, i was told to get some data off a server
somehow, and make a graphical interface to it. talk about software
suicide mission.
Esmond Pitt
This is a multi-part message in MIME format.
--------------7BBF0C7F642D250BF41882B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Edsger Dijkstra pointed out some years ago that all the fuss about
LOC/day was "booking them on the wrong side of the ledger". LOC should
be counted as a cost, not as an output. The fewer the better.
'Superprogrammers' may in many cases produce more LOC/day but this is
not what makes them superprogrammers.
--------------7BBF0C7F642D250BF41882B0
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Esmond Pitt
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Esmond Pitt
n: Pitt;Esmond
org: CP Telemedia Software Laboratories
adr: 493 St Kilda Rd;;;Melbourne;Victoria;3004;Australia
email;internet: pi...@cpgen.cpg.com.au
title: Consultant
tel;work: 61 3 9243 2285
tel;fax: 61 3 9243 2233
tel;home: 61 3 9534 5704
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
end: vcard
--------------7BBF0C7F642D250BF41882B0--
Judson D. McClendon
Esmond Pitt <pi...@cpgen.cpg.com.au> wrote:
> Edsger Dijkstra pointed out some years ago that all the fuss about
> LOC/day was "booking them on the wrong side of the ledger". LOC should
> be counted as a cost, not as an output. The fewer the better.
> 'Superprogrammers' may in many cases produce more LOC/day but this is
> not what makes them superprogrammers.
What good is a 'superprogrammer' who can't produce enough work to earn
their salary? One report program/year is hardly worth it, no matter what
the 'quality' of that program! I agree that quantity alone is a poor
measure. But without a reasonable output, quality is almost irrelevant.
In my opinion, it requires both very high quality and at least good
quantity to qualify as a 'superprogrammer'. Wonder if Dijkstra is a 10
LOC/day programmer? ;-)
Wayne L. Beavers
Many years ago, during a performance review, my supervisor complemented
me on being a lazy programmer. She explained that I had a habit of
thinking about a project long and hard and usually found a way to solve
the problem with far fewer lines of code then had been estimated. The
result was smaller, easier to maintain, and more effecient. I got nice
raises.
A friend of mine has often said "A line NOT coded is a line that WON'T
fail"
Judson D. McClendon
Esmond Pitt <pi...@cpgen.cpg.com.au> wrote:
> Judson D. McClendon wrote:
> > What good is a 'superprogrammer' who can't produce enough work to earn
> > their salary? One report program/year is hardly worth it, no matter
what
> > the 'quality' of that program! I agree that quantity alone is a poor
> > measure. But without a reasonable output, quality is almost
irrelevant.
>
> an output. Outputs are completed programs or working function points or
> signed-off deliverables. Measuring the LOC inside those and counting
> them as 'productivity' is absurd. You might as well count source files,
> or bits, or the number of occurrences of 'zero'.
Measuring LOC is no more 'absurd' than counting programs. Sure, output,
from a logical point of view, is completed programs, or deliverables, or
whatever. But one working program is NOT equivalent to another working
program. In my opinion, that is hardly a better measure than LOC, because
some programs are bigger and take much more code, and some are much more
complex and slower to write, even if smaller. How do you come up with a
numeric measure for that? I don't know; in some ways it is very subjective
and difficult to measure. At bottom, a programmer's value is something
like 'quality times quantity plus other factors'. But developing a
numerical measure of this is problematic.
> We've all seen the very familiar syndrome of programmers trying to
> elevate themselves into the 'super' category, or into the upper pay
> levels that go with it, merely by mass-producing LOC when in most cases
> they should really having been thinking much more and producing much
> less.
I haven't personally noticed that, though I don't doubt it happens
sometimes. But consider: if "we've all seen it", then "we" must all be
able to recognize it, thus it can be taken into consideration and dealt
with by management, no?
> Maybe a superprogrammer is one who earns a high salary. This might be a
> much better measure than LOC.
Possibly. At least it shows someone, for some reason, places a high value
on the quality and/or quantity of the programmer's output. :-)
The Goobers
Judson D. McClendon wrote:
>
> I've said many times that a programmer needs to be two things: lazy enough
> to want to do it the easiest way, and perfectionist enough to do it
> correctly, whatever it takes.
... sounds a bit more reasonable than the pimp who told me that the
client wanted a 'great, heads-down, run-with-the-ball coder who was a
real Team Player'... the following interchange ensued:
Me: 'Hmmm... that is kind of like asking for someone with all the
fierce, *searing* insight of the True Introvert... but he has to be good
with people, too!'
Him: 'Uhhhh, yeah... so, can you do it?'
DD
Judson D. McClendon
I've said many times that a programmer needs to be two things: lazy enough
to want to do it the easiest way, and perfectionist enough to do it
correctly, whatever it takes.
Judson McClendon This is a faithful saying and worthy of all
Sun Valley Systems acceptance, that Christ Jesus came into the
judm...@mindspring.com world to save sinners (1 Timothy 1:15)
(please remove zzz from email id to respond)
Wes Jester
On Fri, 31 Oct 1997 21:38:14 -0500, The Goobers <docd...@erols.com>
wrote:
>Judson D. McClendon wrote:
>>
>> I've said many times that a programmer needs to be two things: lazy enough
>> to want to do it the easiest way, and perfectionist enough to do it
>> correctly, whatever it takes.
>
>... sounds a bit more reasonable than the pimp who told me that the
>client wanted a 'great, heads-down, run-with-the-ball coder who was a
>real Team Player'... the following interchange ensued:
>
>Me: 'Hmmm... that is kind of like asking for someone with all the
>fierce, *searing* insight of the True Introvert... but he has to be good
>with people, too!'
>
>Him: 'Uhhhh, yeah... so, can you do it?'
>
>DD
I am not now, nor have I ever been, a member of the LOC society. I
dispise all those who believe that LOC is a vaild method of
determining productivity. I have used Function Point Analysis and
estimating for over 10 years now and am able to detail a programs
estimate within very reasonable parameters. For us, a function point
equates to certain amount of time to complete - through debugging.
In the begining is was a little difficult to be very good at it
because we needed to learn how to count and to keep good records of
development time. Once that was aacomplished, however, our users
started asking how many FP's in the design as a way to determine
development time and cost.
The correlation has been excellent.
LOC breaks down when one programmer can code a really great routine in
very the minimum of lines, and another programmer, equally as
intelligent, uses more lines to code the same logic. It is just the
way two different people happen to view the same object. However, the
number of function points remain constant and the time to develop
becomes a smoothed curve.
Wes
Richard Anderson
On Mon, 03 Nov 1997 16:51:30 GMT, w...@iag.net (Wes Jester) wrote:
>I am not now, nor have I ever been, a member of the LOC society. I
>dispise all those who believe that LOC is a vaild method of
>determining productivity. ....
>
>LOC breaks down when one programmer can code a really great routine in
>very the minimum of lines, and another programmer, equally as
>intelligent, uses more lines to code the same logic.
One of my favorite moments in programming was when -- oh so many
years ago -- I coded ONE line of PL/1 that generated fourteen
PAGES of assembly language code. When the puppy was run it caused
a 1403 to print ZERO lines for thirty three minutes on a 360/50.
Lesson learned: do not execute a compute-bound program in the
highest priority partition.
--
Rick Anderson
Seattle
anderson aatt pobox fullstop com
The Goobers
Wes Jester wrote:
>
> On Fri, 31 Oct 1997 21:38:14 -0500, The Goobers <docd...@erols.com>
> wrote:
>
> >Judson D. McClendon wrote:
> >>
> >> I've said many times that a programmer needs to be two things: lazy enough
> >> to want to do it the easiest way, and perfectionist enough to do it
> >> correctly, whatever it takes.
> >
> >... sounds a bit more reasonable than the pimp who told me that the
> >client wanted a 'great, heads-down, run-with-the-ball coder who was a
> >real Team Player'... the following interchange ensued:
> >
> >Me: 'Hmmm... that is kind of like asking for someone with all the
> >fierce, *searing* insight of the True Introvert... but he has to be good
> >with people, too!'
> >
> >Him: 'Uhhhh, yeah... so, can you do it?'
> >
> >DD
The last job I held as an employee before I went Independent (at Peat
Marwick in 1986) I would drive folks crazy by spending my Fridays
streamlining my code for greater elegance and efficiency... and the
resulting loss of lines was jokingly referred to as 'negative
productivity'.
It has been said before by the Russians... 'Qualitas, non quantitas'.
DD
RandallBart
Esmond Pitt wrote:
>
> The point is that the wrong thing is being measured. LOC is an input not
> an output. Outputs are completed programs or working function points or
> signed-off deliverables. Measuring the LOC inside those and counting
> them as 'productivity' is absurd. You might as well count source files,
> or bits, or the number of occurrences of 'zero'.
Definitely. On the A Series Cobol Filter we had a negative productivity
standard: Any bug fix was automatically accepted if it reduced the
overall loc in the program (and passed regression test). Sometimes
this meant removing some peripherally related redundancy, but it was a
63,000 loc program, with at least 10,000 loc of redundant code.
> Maybe a superprogrammer is one who earns a high salary. This might be a
> much better measure than LOC.
It's the only true measure of a superprogrammer.
--
I |\ Randall Bart mailto:Bart...@usa.spam.net
L |/ Currently unemployed and broke
o |\ 1-818-985-3259 Please reply without spam
v | \ @worldnet.att.net and @hotmail.com I am also Barticus
e |\ Panic in the Year Zero Zero: http://members.aol.com/PanicYr00
Y |/
o |\ Think You're Smart?
u |/ Can you solve http://members.aol.com/PanicYr00/Sequence.html ?