From: Friedrich Dominicus
Subject: loc measurement for Common Lisp?
Date:
Message-ID: <87wvbw7j58.fsf@frown.here>
Would like to get you ideas about how to count lines in Common Lisp?
(besides the obvious way to just count the physical lines)
What seems to make sense to count e.g comments?
If I had
(defun foo (bar)
" comment for Foo maybe
over more lines and more
and more ..."
(bla bar) ; some comment
;; some other comment
(other-lisp))
Is it two lines of code (bla .. (other
How many comments? One, two, three or more?
Of what about
(and foo bar baz
(< foo bar baz)
(or w1 w2 w3))
of course this is not really a good example but how to "calculate" the
diference between "simple" forms like
(foo bar)
and complex forms?
It would be too interesting of what you think seems to be a sort or
measurement to calculate a size of a project.
My assumptions are (probably totally out of line)
- programmers have a "personal" style of programming and over the time
I guess calculating LOC (by counting physial lines) and a more
complex scheme will yield some relationship (hopefuly with a high
degree of certainty ;-)
- it's hard to tell how all the defxxxxx stuff influences the result,
again it may depend on the programmer and how he/she uses Macros and
other special forms
- it seems to make sense to count comments separatly (very intensively
commented functions may point to a "complex" algorithm, which probably
can be improved)
- other things which may be worth counting separatly is the ratio of
Functions/Macros, generic functions, "usual functions" and the like
- it seems to me that because of Lisps flexibility it will be harder to come
up with such things as e.g in "single" paradigm languages (e.g like C,
even Eiffel etc)
- it seems to be especially difficult to grade the "influence" of
macros which probably are used to write a lot of lines
Just want to point out that are just examples and ideas which have
come to my mind while working on it. I do think there are "better"
ideas arond ;-)
I looked around a bit on google but did not found a somewhat fitting
article and/or software. It would be nice if you could give me a hand
here.
Regards
Friedrich
Friedrich Dominicus wrote in message <··············@frown.here>...
>
>My assumptions are (probably totally out of line)
>- programmers have a "personal" style of programming and over the time
> I guess calculating LOC (by counting physial lines) and a more
> complex scheme will yield some relationship (hopefuly with a high
> degree of certainty ;-)
>- it's hard to tell how all the defxxxxx stuff influences the result,
> again it may depend on the programmer and how he/she uses Macros and
> other special forms
>- it seems to make sense to count comments separatly (very intensively
> commented functions may point to a "complex" algorithm, which probably
> can be improved)
>- other things which may be worth counting separatly is the ratio of
> Functions/Macros, generic functions, "usual functions" and the like
>- it seems to me that because of Lisps flexibility it will be harder to
come
> up with such things as e.g in "single" paradigm languages (e.g like C,
> even Eiffel etc)
>- it seems to be especially difficult to grade the "influence" of
> macros which probably are used to write a lot of lines
I have always done this by counting everything except for empty lines.
I include comments because in well-documented code, the comments
themselves have to be maintained as well.
In my experience, the rough complexity of code written by an experienced
programmer is more related to lines of code than to anything else. This
is because experienced programmers -- I hope! -- tend not to get the
modularity badly wrong, so the numbers of classes and generic functions
tend not to vary wildly. Of course, this is an anecdotal generalization
that would be well worth measuring.
If you believe the LOC is [one of] the most important metrics, then Lisp
(and Dylan!) macros have a profound effect on the complexity of the
code. This is because well-written macros can greatly reduce the
line-count while introducing domain-specific abstraction. This greater
abstraction -- and fewer lines of code -- make the reading of the code
mcuh less difficult. Ease of readability strikes me as a good way to
measure the effect of lessened complexity...
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Would like to get you ideas about how to count lines in Common Lisp?
> (besides the obvious way to just count the physical lines)
Don't.
This rather reminds me of one time on some tv talk show I saw where someone
was trying to explain O(x^2) to the talk host and he went to some trouble to
explain why it wasn't like O(x) at all, and then finally at the end the talk
show host after nodding and nodding like he understood says: "yeah, but so
is it like twice as much or ...?"
Lines of code is an irrelevant metric except in the literal sense of number
of characters typed. And in that sense you might as well measure true lines.
In the sense of measuring the "power" of a line of Lisp code, concern about
whether (and x y) or (and x
y)
will fake you out is an O(x) kind of concern, whereas concern about
whether one writes a macro call or the expanded form of the macro is
definitely something with a higher exponent. So forget about line breaks
and worry about macro calls if you want to know the "power". But on the
other hand, since it takes no more programmer effort to write powerful
macrofied (or functionally abstracted) code than to write basic code,
one comes back to the question:
why are you measuring? If it's to measure programmer productivity, number
of keystrokes is one way to go, but I'd say "meeting schedules with debugged
code" is a better metric. Anything in between these two opposite ends of
the spectrum is probably too confusing to do any good.
If what you're measuring is some other quantity than programmer productivity
but "how much does it do" then I doubt this will be much help.
In article <··············@frown.here>, Friedrich Dominicus wrote:
>
>Would like to get you ideas about how to count lines in Common Lisp?
>(besides the obvious way to just count the physical lines)
i once ran a program i had written (in a paacal derivative) and that doubled
the linecount.
on the same project i took a voluminous piece of code to add some
functionality, and after having done that and adding badly beeded comment
proceeded to clean up some garbage. at the end this piece of code had about
60% of its code size left.
ever since then (actually also before) i considered linecount a completely
irrelevant measure. its only purpuse seems to be management's desire to have
a metric, regardless how use[ful|less] it is
> ...
hs
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87wvbw555q.fsf@frown.here>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@frown.here>, Friedrich Dominicus wrote:
> >
> >Would like to get you ideas about how to count lines in Common Lisp?
> >(besides the obvious way to just count the physical lines)
>
> i once ran a program i had written (in a paacal derivative) and that doubled
> the linecount.
>
> on the same project i took a voluminous piece of code to add some
> functionality, and after having done that and adding badly beeded comment
> proceeded to clean up some garbage. at the end this piece of code had about
> 60% of its code size left.
>
> ever since then (actually also before) i considered linecount a completely
> irrelevant measure. its only purpuse seems to be management's desire to have
> a metric, regardless how use[ful|less] it is
Now I read this opinion quite often. But don't follow it fully. If you
use it for on you own. And spend some time on figuring out what should
be counted and how should it be rated, you learn a lot about
yourself. I did that for another language and it gives me some
invaluable insight on how a good structured programm in that language
will look. So it was at least useful for me, I assume if I find out
what to count and "will be able" to run it on a lot of programs I
probably will find out too how "good structured" Common Lisp will
look.
I'm quite optimistic that I'll find out someday.
What I dislike about your strict opinion that measuring is the
starting point for a lot of areas even in the arts.
I do not claim to know what programming ist. But it seems to me
programming is a strange combination out of science, fiction, art,
writing, craft, psychology . I admit I do not have any clue on what
percantage each
piece contributes, but I do think that science is not the smallest
part. If it isn't than there are useful measures. How good they are to
"measure" someting is dependent on the programmer, and might be hard
to compare.
But I do think if the programmers are open minded and talk about it
internally under "themselves" (no Management) they probably will find
scales which will work for their group. This may be way out of line
and of course YMMV. But saying striclty that locs are useless, is not
helpful.
If you feel they are useless for you, but others don't think so what
do you think will they do? Gathering metrics needs work (maybe even
hard work), not doing it does mean less work. The choice will often be
obvious ....
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
> ...
>What I dislike about your strict opinion that measuring is the
>starting point for a lot of areas even in the arts.
true, but you ought to measure something meaningful.
> ...
>If you feel they are useless for you, but others don't think so what
>do you think will they do? Gathering metrics needs work (maybe even
>hard work), not doing it does mean less work. The choice will often be
>obvious ....
let me explain why i think line count is a particularly bad metric (esp. if
you want to use it to compare languages, which i am not implying your intent
is).
some languages tend to use very long predefined identifiers, and if you look
e.g. at typical lisp or scheme programs, this tends to encourage programmers
let me explain why i think line count is a particularly bad metric (esp. if
you want to use it to compare languages, which i am not implying your intent
is).
line count tends to be heavily influenced by programming style. e.g.
somebody who tends to use long identifiers are more often forced to break
a line into two (or more), giving a different metric for otherwise identical
code. the same is true if you use a language that tends to have long
predefined identifiers. write an identical program in a language that tends
to use brief keywords or relies heavily on a rich character set, and you end
up with a measure that differs grossly from the program you started out with
(maybe token count would be a better starting measure). this fact alone
makes loc a totally useless metric.
my other problem is that loc completely ignores a component of programs that
imo is quite essential: the structuring of the program.
i would suggest that you have a look at a book that was published some time in
the 1970s, "software metric". the author was a guy named halpern or halperin.
he was discussing a couple of possible metrics for programs that he considered
meaningful. afair, it was more an attempt to get the ball towards meaningful
metrics rolling. i don't remember much, but i think his main trust was to
catch a measure of the complexity of a program, e.g. how deep decision trees
are nested etc. i don't know what came out of this effort, but afaict it has
been pretty quiet about this subject since. but it might still give you some
ideas about where to start.
hs
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87puhmy80u.fsf@frown.here>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@frown.here>, Friedrich Dominicus wrote:
> > ...
> >What I dislike about your strict opinion that measuring is the
> >starting point for a lot of areas even in the arts.
>
> true, but you ought to measure something meaningful.
>
> > ...
> >If you feel they are useless for you, but others don't think so what
> >do you think will they do? Gathering metrics needs work (maybe even
> >hard work), not doing it does mean less work. The choice will often be
> >obvious ....
>
> let me explain why i think line count is a particularly bad metric (esp. if
> you want to use it to compare languages, which i am not implying your intent
> is).
>
> some languages tend to use very long predefined identifiers, and if you look
> e.g. at typical lisp or scheme programs, this tends to encourage programmers
>
> let me explain why i think line count is a particularly bad metric (esp. if
> you want to use it to compare languages, which i am not implying your intent
> is).
>
> line count tends to be heavily influenced by programming style. e.g.
> somebody who tends to use long identifiers are more often forced to break
> a line into two (or more), giving a different metric for otherwise identical
> code. the same is true if you use a language that tends to have long
> predefined identifiers. write an identical program in a language that tends
> to use brief keywords or relies heavily on a rich character set, and you end
> up with a measure that differs grossly from the program you started out with
> (maybe token count would be a better starting measure). this fact alone
> makes loc a totally useless metric.
I admit that I do think it's hard to come up with metrics for Lisp
because of it's flexibility. But I'm quite sure that one can gather
different metrics and that the correlate with the LOC somehow. That is
a hypotheses!. Now how can one find out if it holds or not. You collect
and collect and ... and after while you can give it a try. If you
found nothing which supports your initial idea. There is probably no
relationship. Anyway without trying it won't work, have you?
You answer implies no. So your hypotheses is "LOC is useless" but you
have not done anything to confirm or rebut it. It's of course your
free decision but you should not state is is useless but that you
consider it to be useless that is a major difference.
>
> my other problem is that loc completely ignores a component of programs that
> imo is quite essential: the structuring of the program.
>
> i would suggest that you have a look at a book that was published
>some time in
> the 1970s, "software metric". the author was a guy named halpern or
>halperin.
> he was discussing a couple of possible metrics for programs that
>he considered
> meaningful. afair, it was more an attempt to get the ball towards meaningful
> metrics rolling. i don't remember much, but i think his main trust was to
> catch a measure of the complexity of a program, e.g. how deep decision trees
> are nested etc. i don't know what came out of this effort, but afaict it has
> been pretty quiet about this subject since. but it might still give you some
> ideas about where to start.
There are a lot of books available about metrics and there are simple
and difficult metrics available (check e.g Horst Zuse, Software
complexity measures and methods; DeGruyter) You may talk about
Halsteads metrics like Volume, Difficulty etc. or Maybe McCabes
cyclomatic complexity.
However the problem is that all the offered tools to gather metrics
assume languages like C, Java, Pascal. So let's say imperative and/or
objectoriented languages. This languages are less flexible as Lisp is
and because of the Flexibility I expect finding useful Metrics
harder. But that does not mean it can not work. If nobody has tried
before than it's an open question.
Now one starting point is to count the simple things. If in doubt
count the physical lines. You than can add comments, nesting of
conditions etc. So I can think about a lot of metrics but because I do
not feel as comfortable in Lisp I asked what "used" Lisp users think,
might be a good one.
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
> I admit that I do think it's hard to come up with metrics for Lisp
> because of it's flexibility.
If you get paid by LOC make sure:
- you macro expand your source code on all levels when saving your files. ;-)
A code walker definitely helps.
- you set *print-circle* to nil before printing data structures ;-)
- you tweak the pretty printer to format your code nicely
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87lmsay656.fsf@frown.here>
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@frown.here>, Friedrich Dominicus
> <·····@q-software-solutions.com> wrote:
>
> > I admit that I do think it's hard to come up with metrics for Lisp
> > because of it's flexibility.
>
> If you get paid by LOC make sure:
Does there exist just any programmer paid for that?
So I try to re-state:
- it's for learning the PSP
- it's for me
- it was a question on what makes sense to count assuming
- "work" the usual way
- have I mentioned (it's for you personal use?)
- you had some idea on how you usually wrote you programs
Have I mentioned it's for personal use?
;-)
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > In article <··············@frown.here>, Friedrich Dominicus
> > <·····@q-software-solutions.com> wrote:
> >
> > > I admit that I do think it's hard to come up with metrics for Lisp
> > > because of it's flexibility.
> >
> > If you get paid by LOC make sure:
>
> Does there exist just any programmer paid for that?
>
> So I try to re-state:
>
> - it's for learning the PSP
> - it's for me
> - it was a question on what makes sense to count assuming
> - "work" the usual way
> - have I mentioned (it's for you personal use?)
> - you had some idea on how you usually wrote you programs
>
>
> Have I mentioned it's for personal use?
Sure.
Btw., on the CL-HTTP home page (http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html)
go to "6. Latest Common Lisp Sources". Click on "Latest".
Maybe give it some time. Displays the number of characters, lines and
definitions for the system CL-HTTP. Actually this is just
a call of SCT:COUNT-LINES-IN-SYSTEM on the Lisp Machine.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Friedrich Dominicus <·····@q-software-solutions.com> writes:
Does there exist just any programmer paid for that?
i hear some programmers get paid by the line <snort!>
So I try to re-state:
- it's for learning the PSP
- it's for me
- it was a question on what makes sense to count assuming
- "work" the usual way
- have I mentioned (it's for you personal use?)
- you had some idea on how you usually wrote you programs
Have I mentioned it's for personal use?
;-)
if it's for personal use, what good are other people's ideas concerning
your chosen metrics? how do you expect to hook freshwater fish in the
ocean that is comp.lang.lisp?
thi
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87u26xtijh.fsf@frown.here>
thi <···@glug.org> writes:
>
> if it's for personal use, what good are other people's ideas concerning
> your chosen metrics?
Please read the first mail. I asked not just on LOC but on metrics
which seems to make sense to count in Common Lisp. Who should no
better but Common Lisp programmer?
>how do you expect to hook freshwater fish in the
> ocean that is comp.lang.lisp?
What do you mean by this?
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
Please read the first mail. I asked not just on LOC but on metrics
which seems to make sense to count in Common Lisp. Who should no
better but Common Lisp programmer?
possibly, no metric devolving to simple counting makes sense, and that
each person's sense is built on their unique experience, thus rendering
experienced programmers unable to answer your question in kind?
> how do you expect to hook freshwater fish in the
> ocean that is comp.lang.lisp?
What do you mean by this?
NaCl is to a stream trout hell
in seasoned newsgroups some questions dwell.
NaCl most sunfish do not abide
comforting yellow flame, gentle and snide.
osmosis prevented by a membrane non-porous.
stupifying punditry; feel free to ignore us.
what do you mean by this?, we wonder.
can you, these 8 lines, 56 words, now plunder?
thi
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87y9w9ngg8.fsf@frown.here>
thi <···@glug.org> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> Please read the first mail. I asked not just on LOC but on metrics
> which seems to make sense to count in Common Lisp. Who should no
> better but Common Lisp programmer?
>
> possibly, no metric devolving to simple counting makes sense.
Is that really the case?
>and that
> each person's sense is built on their unique experience, thus rendering
> experienced programmers unable to answer your question in kind?
Ok accepted and how can the experience programmer know if and how he
improves?
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> thi <···@glug.org> writes:
>
> > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> >
> > Please read the first mail. I asked not just on LOC but on metrics
> > which seems to make sense to count in Common Lisp. Who should no
> > better but Common Lisp programmer?
> >
> > possibly, no metric devolving to simple counting makes sense.
> Is that really the case?
>
>
> >and that
> > each person's sense is built on their unique experience, thus rendering
> > experienced programmers unable to answer your question in kind?
> Ok accepted and how can the experience programmer know if and how he
> improves?
have you tried "the tao of programming"? while old it is still
relevant. you can search but here is one (of many) url ---
<URL:http://www.dnaco.net/~kragen/tao-of-programming.html>
for me, learning lisp (and i still a rank beginner) the difficulty
seemed to consist more of losing old ways than acquiring new ones.
you will have to let go of some preconceived notions. it *is* hard.
i see that you search for a performance metric. how can you judge
until you understand? try doing some lisp. try reading some books on
lisp. get a feeling for quality. read the zen of motorcyle
maintainence. *then* find a way to measure.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
sysengr
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87d7dkna1c.fsf@frown.here>
Johan Kullstam <········@ne.mediaone.net> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > thi <···@glug.org> writes:
> >
> > > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > >
> > > Please read the first mail. I asked not just on LOC but on metrics
> > > which seems to make sense to count in Common Lisp. Who should no
> > > better but Common Lisp programmer?
> > >
> > > possibly, no metric devolving to simple counting makes sense.
> > Is that really the case?
> >
> >
> > >and that
> > > each person's sense is built on their unique experience, thus rendering
> > > experienced programmers unable to answer your question in kind?
> > Ok accepted and how can the experience programmer know if and how he
> > improves?
>
> have you tried "the tao of programming"? while old it is still
> relevant. you can search but here is one (of many) url ---
>
> <URL:http://www.dnaco.net/~kragen/tao-of-programming.html>
>
> for me, learning lisp (and i still a rank beginner) the difficulty
> seemed to consist more of losing old ways than acquiring new ones.
> you will have to let go of some preconceived notions. it *is* hard.
>
> i see that you search for a performance metric.
No, as I told before it to to the excercises from Watts
Humphreys Book. I dont claim to know the ins and outs of Lisp anyway,
otherwise I probably would know what would make sense to count. As
stated before I spend a good amount on time to build a measurement
system for a language I do think I understand fully. And it took me
more than half a year. Anyway the excercises which follow are based on
estimates on a loc counter. So if I want to do it in Lisp and I will I
have to start somewhere.
> how can you judge
> until you understand?
Good points but I spend a lot of time with lisp the last year and do
think that I understand a bit of it.
>try doing some lisp.
Oh I'm using it
>try reading some books on
> lisp.
I read at least 4-5 which were recommended. Some more than
once. Anyway nowhere is a hint on what I want to do know. It's about
Common Lisp in general, the Object System, the Meta Object Protocol,
about Macros and/or Artificial Intelligence (and wider area). There is
a lot written about what Lisp is good at, but no book pointed me out
to the area I'm now interested in. So I asked ...
> get a feeling for quality.
That is a bit of a problem for Lisp. I do think I found it elsewhere,
but that does not help much.
> *then* find a way to measure.
Again PSP is about thinking along the lines of logical lines. And take
that as a base for size estimates and time estimates. I may to point
out to Gabriels Patterns of software or Weinberger or McConnell. There
is one episode in which one of the authors (sorry do not know the
place more exaclty) state. Write it down, make a sketch and see how it
turns out to be really. They suggest judge things for all areas of
Software Engeneering. I found their argumentation quite
convincing. And so I try to learn estimating.
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
>I read at least 4-5 which were recommended. Some more than
>once. Anyway nowhere is a hint on what I want to do know. It's about
>Common Lisp in general, the Object System, the Meta Object Protocol,
>about Macros and/or Artificial Intelligence (and wider area). There is
Try "The Art of the Metaobject Protocol", an absolutely fascinating book
from MIT Press by Kiczales et al for CLOS; "Paradigms of Artificial
Intelligence Programming" is good for basic AI stuff. Norvig has
written another more comprehensive (although not as deep) textbook on AI
that's pretty good, but I forget what the name of it is offhand. Should
be able to search for it at your favorite online bookstore.
--
</nathan> ·······@rose-hulman.edu | http://www.rose-hulman.edu/~froydnj/
Yes, God had a deadline. So He wrote it all in Lisp.
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87lms8934n.fsf@frown.here>
·······@rose-hulman.edu (Nathan Froyd) writes:
>
> Try "The Art of the Metaobject Protocol", an absolutely fascinating book
> from MIT Press by Kiczales et al for CLOS; "Paradigms of Artificial
> Intelligence Programming" is good for basic AI stuff. Norvig has
> written another more comprehensive (although not as deep) textbook on AI
> that's pretty good, but I forget what the name of it is offhand. Should
> be able to search for it at your favorite online bookstore.
I guess you misunderstood. I read all the books you recommend but did
not find in any of this books hints on estimating. There are other
books which cover this, but they just cover "imperative" and/or
objectoriented languages.
I can just recommend all interested in Lisp to read the mentioned
books. They are among my favourite Computer Science Books.
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
> ...
>stated before I spend a good amount on time to build a measurement
>system for a language I do think I understand fully. And it took me
>more than half a year. Anyway the excercises which follow are based on
my problem with this metrics approach is that essentially it concentrates
on the least important part of what a programmer is (imo) supposed to do:
analysing a problem and coming up with a solution for it. what you are
analyzing (at least the way i understood it) is of relevance only to coders
who get fed a problem solution and translate it into compilable code. big
deal
hs
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87wvbsghya.fsf@frown.here>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@frown.here>, Friedrich Dominicus wrote:
> > ...
> >stated before I spend a good amount on time to build a measurement
> >system for a language I do think I understand fully. And it took me
> >more than half a year. Anyway the excercises which follow are based on
>
> my problem with this metrics approach is that essentially it concentrates
> on the least important part of what a programmer is (imo) supposed to do:
> analysing a problem and coming up with a solution for it. what you are
> analyzing (at least the way i understood it) is of relevance only to coders
> who get fed a problem solution and translate it into compilable code. big
> deal
It's one part of learning the PSP the other are. Keeping Plans,
estimate times you spend in each stage, keeping track of time,
defects and fixing of bugs, code reviews and a bunch of other
things. Anyway part of the whole thing is estimating sizes too. I just
can suggest look into that book "A discipline for software
engineering" and judge it yourself.
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
>Johan Kullstam <········@ne.mediaone.net> writes:
>
>> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>>
>> > thi <···@glug.org> writes:
>> >
>> > > Friedrich Dominicus <·····@q-software-solutions.com> writes:
>> > >
>> > > Please read the first mail. I asked not just on LOC but on metrics
>> > > which seems to make sense to count in Common Lisp. Who should no
>> > > better but Common Lisp programmer?
>> > >
>> > > possibly, no metric devolving to simple counting makes sense.
>> > Is that really the case?
>> >
>> >
>> > >and that
>> > > each person's sense is built on their unique experience, thus rendering
>> > > experienced programmers unable to answer your question in kind?
>> > Ok accepted and how can the experience programmer know if and how he
>> > improves?
>>
>> have you tried "the tao of programming"? while old it is still
>> relevant. you can search but here is one (of many) url ---
>>
>> <URL:http://www.dnaco.net/~kragen/tao-of-programming.html>
>>
>> for me, learning lisp (and i still a rank beginner) the difficulty
>> seemed to consist more of losing old ways than acquiring new ones.
>> you will have to let go of some preconceived notions. it *is* hard.
>>
>> i see that you search for a performance metric.
>No, as I told before it to to the excercises from Watts
>Humphreys Book. I dont claim to know the ins and outs of Lisp anyway,
>otherwise I probably would know what would make sense to count. As
>stated before I spend a good amount on time to build a measurement
>system for a language I do think I understand fully. And it took me
>more than half a year. Anyway the excercises which follow are based on
>estimates on a loc counter. So if I want to do it in Lisp and I will I
>have to start somewhere.
If you want to find out if you are improving as a programmer then try
this:
1: write a program that is hard for you to do now, pick something.
2: continue to learn your craft for 6 months
3: rewrite the same program
4: compair them and see if there is any improvement
it is a very coarse metric but it will give you a feel of what you are
doing. And do a code review on your work every month for the projects
you have done in the last 6 months. Keep notes on what you would
change in the old projects and compair the notes from month to month.
see how your skill have improved or at least how your ideas have
changed.
good luck
marc
>
>> how can you judge
>> until you understand?
>Good points but I spend a lot of time with lisp the last year and do
>think that I understand a bit of it.
>
>>try doing some lisp.
>Oh I'm using it
>
>
>>try reading some books on
>> lisp.
>I read at least 4-5 which were recommended. Some more than
>once. Anyway nowhere is a hint on what I want to do know. It's about
>Common Lisp in general, the Object System, the Meta Object Protocol,
>about Macros and/or Artificial Intelligence (and wider area). There is
>a lot written about what Lisp is good at, but no book pointed me out
>to the area I'm now interested in. So I asked ...
>
>
>> get a feeling for quality.
>That is a bit of a problem for Lisp. I do think I found it elsewhere,
>but that does not help much.
>
>
>> *then* find a way to measure.
>Again PSP is about thinking along the lines of logical lines. And take
>that as a base for size estimates and time estimates. I may to point
>out to Gabriels Patterns of software or Weinberger or McConnell. There
>is one episode in which one of the authors (sorry do not know the
>place more exaclty) state. Write it down, make a sketch and see how it
>turns out to be really. They suggest judge things for all areas of
>Software Engeneering. I found their argumentation quite
>convincing. And so I try to learn estimating.
>
>Regards
>Friedrich
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <871yu0hwq7.fsf@frown.here>
····@oscar.eng.cv.net (Marc Spitzer) writes:
>
> If you want to find out if you are improving as a programmer then try
> this:
> 1: write a program that is hard for you to do now, pick something.
> 2: continue to learn your craft for 6 months
> 3: rewrite the same program
> 4: compair them and see if there is any improvement
>
> it is a very coarse metric but it will give you a feel of what you are
> doing. And do a code review on your work every month for the projects
> you have done in the last 6 months. Keep notes on what you would
> change in the old projects and compair the notes from month to month.
>
> see how your skill have improved or at least how your ideas have
> changed.
This is an excellent advise. By chance I had done something simular in
the past. Just the thing I did not, was keeping notes. So I can just
say it was much easier to do the second time and it was rounded up
better. (Unfortunatly just a feeling)
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
Ok accepted and how can the experience programmer know if and how he
improves?
the experienced programmer looks at old code and sees it differently.
thi
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87bssw5aeb.fsf@frown.here>
thi <···@glug.org> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> Ok accepted and how can the experience programmer know if and how he
> improves?
>
> the experienced programmer looks at old code and sees it
>differently.
What does that mean sees it differently? I see this thread a bit
differently than I did before so what?
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
What does that mean sees it differently? I see this thread a bit
differently than I did before so what?
i like your questions much better now!
(for one, they're much shorter... :-)
"so what", indeed?
if you were to attempt the same thing (finding out about personal
metrics with the goal of improving your programming skills) again, what
would you do differently? and why? what different assumptions /
optimizations / design paths would you take into account before and
throughout the process? who would you trust to call?
zamm <http://skynet.ul.ie/~chopper/zen/> author pirsig points out that
quality lies in perception. what is the quality of LOC? what is the
quality of the above questions? what is the general relationship
between quantity and quality?
damn, it's a nice day, gotta go for a ride...
thi
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> thi <···@glug.org> writes:
>
> > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> >
> > Ok accepted and how can the experience programmer know if and how he
> > improves?
> >
> > the experienced programmer looks at old code and sees it
> >differently.
> What does that mean sees it differently? I see this thread a bit
> differently than I did before so what?
Yeah, of course -- you don't know how to "count" difference.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87elxqtf11.fsf@frown.here>
Janis Dzerins <·····@latnet.lv> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > thi <···@glug.org> writes:
> >
> > > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > >
> > > Ok accepted and how can the experience programmer know if and how he
> > > improves?
> > >
> > > the experienced programmer looks at old code and sees it
> > >differently.
> > What does that mean sees it differently? I see this thread a bit
> > differently than I did before so what?
>
> Yeah, of course -- you don't know how to "count" difference.
Great, answer and really useful. If I had not open that thread and did
not have got some good answers how should I see things differently?
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
>
> Ok accepted and how can the experience programmer know if and how he
> improves?
what i always found helpful to sit down at the end of a project and think
about what i would do different the next time, also write it down. later
on when doing the same evaluation for your next project, check those notes
and see whether you followed your own advice ;-)
hs
Erik Naggum <····@naggum.net> writes:
> I'm quite sure that one can correlate software with caffeine consumption.
> This is not entirely facetious. I think people need more caffeine, and
> some probably nicotine, to think and concentrate better, and that if you
> have a hard problem to crack, you probably consume more caffeine, too.
Let's not forget the other happy helpers; ephedrine, thc, beer, and sex.
I'd like to see some metrics for those. Pay programmers per shag?
In article <··············@piracy.red-bean.com>, Craig Brozefsky
<·····@red-bean.com> wrote:
[snip]
>I'd like to see some metrics for those. Pay programmers per shag?
hmmm, as a married man whose wife is always wondering why her programmer
husband doesn't make more money, i like the thinking behind this metric...
sashank
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <878zoaw2l4.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> I'm quite sure that one can correlate software with caffeine consumption.
> This is not entirely facetious. I think people need more caffeine, and
> some probably nicotine, to think and concentrate better, and that if you
> have a hard problem to crack, you probably consume more caffeine, too.
> Your LOC can be Liters Of Coffee and make a better metric.
If you LOC is Litres of Cofee fine. I do not have any problem with
it. Anyway I was thinking that it might be a bit more related to
programming ;-)
>
> To repeat myself, the more I understand a problem, the less code I write.
> (This may not correlate with the documentation -- Often it takes more
> text to explain a brief piece of code than lots of code.) I have this
> idea that if you give the same problem to a bunch of programmers, the
> most competent will produce the fewest lines of code, and the least
> competent the most lines of code, but the productivity of the least
> competent programmer will be much higher than the most competent
> programmer in terms of lines of code per unit of time.
That is not my experience. It depends much on how many things are
factored out, how you deal with reusable components etc.
>
> "There is no evidence that LOC correlates to anything useful" is not the
> stupid statement you want it to be when phrased as "LOC is useless", but
> that is what it means. It doesn't say "there is much evidence to support
> an utter lack of usefulness of LOC", which is what it would have to mean
> if someone needed to "confirm or rebut it".
So please point me to a pointe where this is stated. I will quite
happily find another on in which LOCs are useful.
>Again, your whole scheme is
> lacking in scientific rigor, and the likelihood that you will get
> anything out of it that has not been extrapolated from one data point is
> very slim. This is very, very annoying to people who would like to see
> useful metrics or useful discussion around metrics.
So please make a suggestion. What seems to make sense?
>
> It is not intended as a slight towards foreign authors who still write in
> their native language despite some English grammar and vocabulary, but
> code written by people who live in cultures that make people think they
> don't need English, also tends to be massively verbose compared to those
> who break with that notion and learn English very well, simply because
> programming languages and literature are (usually) in English.
Even if, it does not say anything about how useful LOCs are for that
person. I try to clarify what I think. Because I do not no better yet
I assume that LOC may be related to the effort I spend on solving a
problem. It's an simple way of putting the size of a software in a
scale. 10 LOC are surely shorter than 1000 LOC. (No I do not talk
about generated code, just a piece of software written by someone.) If
I know that I usually write, delete, modify x LOC/h than I can say
for 10 LOC I do not x Minutes and if we assume that it is a linear
relationship than I need y Minutes for 1000 Lines.
I see all the shortcomings.
- do you know about the area for which you wrote the code
- is is part of a larger project or is it just to "show" one point
etc etc.
If you collect this stuff regularly. And you know the area. You might
know last time I wrote a simular thing I needes xt hours. Now I do
think xp % are different and are an area I do not know as well, but I
know that last time I had to do something new it took me yt hours so I
guess I will need xt*(1-xp)+yt(xp) = tt hours. If you can do that and
Watts Humprehy book is just about such things, you are know a bit more
of you work than a lot of other programmers.
All the mentioned reasons against and for metrics have been discussed
intensivly. Fair enough a lot of books suggest starting collecting
data to know more. And that are not the worst books I guess. Because
it is complex it may or may not be naive to take LOC. As I mentioned
more than once it's about learning the PSP and there are a lot of
reports out there which seem to indicate it works. But there is at
least one report where it is stated that it depends on the skill of
the programmer.
However your experience is. It's interesting, and it forces me to
think about things, and because you keep timelogs in the PSP
excercises you see how much time is spend where.
> This will
> affect the line of code and comment counts much more than anything else
> in my experience. You will therefore measure programmer competence and
> language skills if you measure lines of code and any other values you
> would like to get out of this measurement will probably drown in that
> noise.
This is a very good point. Again I do think it's an open question.
However we're drifting off-topic and so let's go back.
What may be a metrics which can help improving yourself to improve on
developing software. Maybe you don't bother, but I do.
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
> ...
>> very slim. This is very, very annoying to people who would like to see
>> useful metrics or useful discussion around metrics.
>
>So please make a suggestion. What seems to make sense?
you seem to have looked into it quite thoroughly, at least in respect to
procedural ond object oriented languages. why don't you start by taking
those measures that you find useful there and try to apply them to lisp.
after all, lisp is just another language, though i think one of the languages
the give you an above average problem solving productivity.
regarding your earlier statement on the usefulness of your endeaver: if you
really think that a metric that can give you vastly different results for
structurally identical programs, be my guest (i did suggest in my earlier post
that if you really start with simple counting, a token count would be
considerably less useless than a line count; at least it would get you
identical results for structurally identical code). i still think that any
meaningful metric would require taking into account the structure of the code
> ...
hs
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87y9w9timv.fsf@frown.here>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@frown.here>, Friedrich Dominicus wrote:
> > ...
> >> very slim. This is very, very annoying to people who would like to see
> >> useful metrics or useful discussion around metrics.
> >
> >So please make a suggestion. What seems to make sense?
>
> you seem to have looked into it quite thoroughly, at least in respect to
> procedural ond object oriented languages. why don't you start by taking
> those measures that you find useful there and try to apply them to lisp.
> after all, lisp is just another language, though i think one of the languages
> the give you an above average problem solving productivity.
This is what I'm doing. But I do not know how to grade the use of
macros and the OO-System is totally different from anything I have
known before. The structure of the programs in the other language is
far less flexibel (e.g one file per class etc)
> that if you really start with simple counting, a token count would be
> considerably less useless than a line count; at least it would get you
> identical results for structurally identical code). i still think that any
> meaningful metric would require taking into account the structure of
>the code
I agree. I do think I found a nice solution for another langauge, but
I have not come up yet with a solution I find as nice for Lisp. Anyway
the other system has been developed within more than 6 month (full
time);-) Another point is that my programs have a simular structure
(nearly) always I do not change the way I wrote from one program to
another. So I neglect the structure. And of if that is not considered
to be variable ...
Regards
Friedrich
Friedrich Dominicus wrote:
>
> ··@paradise.nirvananet (Hartmann Schaffer) writes:
>
> > In article <··············@frown.here>, Friedrich Dominicus wrote:
> > > ...
> > >> very slim. This is very, very annoying to people who would like to see
> > >> useful metrics or useful discussion around metrics.
> > >
> > >So please make a suggestion. What seems to make sense?
> >
> > you seem to have looked into it quite thoroughly, at least in respect to
> > procedural ond object oriented languages. why don't you start by taking
> > those measures that you find useful there and try to apply them to lisp.
> > after all, lisp is just another language, though i think one of the languages
> > the give you an above average problem solving productivity.
>
> This is what I'm doing. But I do not know how to grade the use of
> macros and the OO-System is totally different from anything I have
> known before. The structure of the programs in the other language is
> far less flexibel (e.g one file per class etc)
>
> > that if you really start with simple counting, a token count would be
> > considerably less useless than a line count; at least it would get you
> > identical results for structurally identical code). i still think that any
> > meaningful metric would require taking into account the structure of
> >the code
>
> I agree. I do think I found a nice solution for another langauge, but
> I have not come up yet with a solution I find as nice for Lisp. Anyway
<snip>
> Regards
> Friedrich
The question that is begged from the initial trivial one of LOC is one
of the most deep questions a programmer can ask, so no trivial answer
can be accepted.
For a metric, consider how many functions, macros, defclasses and
methods are defined, and multiply each by the (estimated) probability
that each of them might ever be used again elsewhere. The result would
be some effective Lisp object count. While this contains some
subjectivity in terms of the estimate of re-use, any totally objective
counting metric is useless anyway, as others in this thread have
expended much bandwidth pounding home.
Having spent over 16 years programming professionally in Lisp, IMHO
elegance and abstractness are the hallmarks of quality in Lisp
programs. Elegance is difficult to measure (except maybe in inverse
LOC) but abstractness tends to render code re-usable. I consider Paul
Graham's On Lisp to contain many gems and a useful guide as to how to
improve.
HTH,
Raymond Laning
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | So please point me to a pointe where this is stated. I will quite
> | happily find another on in which LOCs are useful.
>
> Where is _what_ stated? And find what? If you want an honest suggestion
> on what you should spend your time doing: Improve your English skills.
> It will pay off very well in your programming, too, as I think I told you
> in not so subtle ways in the message you respond to, but you're not
> receiving on the hint port today, are you?
> It looks like you have the answer (LOC) and are looking for the
> question.
Indeed.
It's reasonably likely that the _longest_ solution to a problem, in
terms of number of lines of code, as well as the _shortest_, may both
have pathological properties of one variety or another that establish
that they are somehow undesirable.
For instance, a fairly complex algorithm might get expressed as:
a) An staggeringly long set of "nested if statements" that is
difficult for the mind to keep in mind since there are so many
clauses;
b) A staggeringly long single line of APL code that causes grieviously
complicated operators to interact in capricious ways to achieve the
answer.
And then there might be some third way that involves breaking the
problem into some more comprehensible independent subproblems, so that
it is fairly easy to follow the various steps of the algorithm.
An LOC measure or a "complexity measure" or such can probably provide
numbers that tell you what you _already knew_, if you had a) or b),
which was that the solution scheme was _just too complicated to live
with_.
In the "real world," it's likely that an "elegant" solution may be
better than its alternatives. Unfortunately, there is no clear
numerical measure for "elegance."
--
(reverse (concatenate 'string ··········@" "enworbbc"))
<http://www.ntlug.org/~cbbrowne/linux.html>
Rules of the Evil Overlord #20. "Despite its proven stress-relieving
effect, I will not indulge in maniacal laughter. When so occupied,
it's too easy to miss unexpected developments that a more attentive
individual could adjust to accordingly."
<http://www.eviloverlord.com/>
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <873dehuxoq.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | So please point me to a pointe where this is stated. I will quite
> | happily find another on in which LOCs are useful.
>
> Where is _what_ stated? And find what? If you want an honest suggestion
> on what you should spend your time doing: Improve your English
>skills.
Where is it stated that LOC are useless. I don't think that the hint
on improving my english is anyway related to the subject.
>
> | So please make a suggestion. What seems to make sense?
>
> It this a joke? I should make a suggestion? How about "don't waste your
> time counting lines of code"? How many ways to you want this
>served?
Oh, very nice. I see "don't count lines of code". I asked for another
thing to count which makes sense.
>
> | What may be a metrics which can help improving yourself to improve on
> | developing software. Maybe you don't bother, but I do.
>
> Christ, dude, just because you have found the Holy fucking Grail doesn't
> mean those who think you found a toilet roll wouldn't also like to find
> some Holy Grail of their own, but don't insult people just because they
> think Lines of Code has been lacking in usefulness over many
>years.
Nowhere did I insult anyone. I did not claim anywhere that I found a
solution. So please come back to the subject.
> If
> it were so great, wouldn't something have come out of it? Why do people
> not count lines of code, anymore? If you want to improve, here's a
> suggestion that goes directly to programming, too: Don't make up your
> mind before you know what to make it up with. (Apply to
>optimization.)
Not all a counting lines of code. But a lot are and a lot of books
recommend starting collecting data.
>
> It is because I think Lines of Code is bordering on insane _and_ I think
> becoming a better programmer is important that I say everything I can to
> get you and everybody else away from the insanely useless measures. But
> you insist on counting lines! You even think that people who don't count
> lines aren't interested in becoming better programmers! Are you
>_nuts_?
I did not say anything like that and do not think that I'm more nuts
as others ...
>
> I think you should go back to the question to which LOC is not the answer
> and try to answer it _honestly_ and openly this time. LOC is a dead end.
> It has been for many, many years.
Is it really. Strange that Watts Humphry suggested counting lines of
code counting lines of code for object etc. Strange that I found other
suggestions in books of Steve McConnell, and or Weinberger and or ...
I understand clearly that you refuse to see any sense in counting
LOC. That's obviously fine for you.
Friedrich
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87puhkncoo.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | Where is it stated that LOC are useless.
>
> Here! Several people have said so. Damnit, can't you _read_,
>either?
That were two (you included) seems to be not several ;-)
>
> | I don't think that the hint on improving my english is anyway related to
> | the subject.
>
> Then you are not really interested in improving your programming
>skills.
Interesting conclusion.
>
> | > | What may be a metrics which can help improving yourself to improve on
> | > | developing software. Maybe you don't bother, but I do.
> | >
> | > Christ, dude, just because you have found the Holy fucking Grail
> | > doesn't mean those who think you found a toilet roll wouldn't also
> | > like to find some Holy Grail of their own, but don't insult people
> | > just because they think Lines of Code has been lacking in usefulness
> | > over many years.
> |
> | Nowhere did I insult anyone. I did not claim anywhere that I found a
> | solution. So please come back to the subject.
>
> Oh, geez. The _real_ subject seems to be your personal
>improvement.
Do you think so? I asked what makes sense to count. LOC isn't the
answer obviously for you.
> You
> reject every suggestion that could cause real personal improvement, and
> hang on to lines of code like it was a Holy Grail, then _insult_ people
> who don't like that insanely useless measure by saying something so
> stupid as "maybe you don't bother [to improve yourself]".
I reject every suggestion? The thing I did understand is that you do
not think LOC are useful. And someone else has stated the same
opinion.
>I'm never going to hire you,
>anyway.
I would appriciate if you would stay away from any offer ;-) This is
at least solved than.
>
> | Not all a counting lines of code. But a lot are and a lot of books
> | recommend starting collecting data.
>
> And you believe all the books, and nothing people tell you here?
>Why?
I do not believe all I can read in the books and I do try to get
your opinion. It's clear to me that two have stated clearly that they
found LOC to be useless. Again that's fine for me. Anyway I do
consider some of the books I read to be written by people who have a
different opinion. I have not made up my mind yet. Just so much while
doing a simular thing (just counting) in another language I do found
some interesting numbers. I did not expect too much but the results
were very interesting.
>
> | I did not say anything like that and do not think that I'm more nuts
> | as others ...
>
> So what _does_ "Maybe you don't bother [to improve yourself]"
>mean?
How to you measure your progress?
>
> | Is it really. Strange that Watts Humphry suggested counting lines of
> | code counting lines of code for object etc. Strange that I found other
> | suggestions in books of Steve McConnell, and or Weinberger and or ...
>
> So you have made up your mind long before you know what to make it up
> with. You really didn't come here to hear any suggestions, but to have
> people pat your back and approve of lines of code as the solution,
> right?
No I asked what makes sense to count. I understand that LOC is not the
answer for some of you. What do you suggest (besides improving my
english)?
>
> | I understand clearly that you refuse to see any sense in counting
> | LOC. That's obviously fine for you.
>
> You know, your pathetic display of reading comprehension makes it wholly
> useless to waste any more lines of _anything_ on you. You aren't going
> to improve yourself in any relevant way until you really start to listen
> to what people tell you, which you don't do today at all, so I think you
> should just go back to the _books_ that "helped" you make up your mind
> prematurely and just go ahead collect "data" and see if you get
>anywhere.
Thanks that is a good suggestion. I do think I will follow it.
> You are already wasting your time, so it should be _really_ easy to see
> improvement no matter what you do, but I really think you ought to spend
> a _lot_ of time reading and writing English with people who are willing
> to help correct you and help you improve your natural language skills,
> because you sure don't pay enough attention to how other people write and
> spell to make use of such observations. That is a clear sign to me that
> you are not going to succeed in improving yourself in any way, because
> the first rule of improvement is to observe the effects of what you do,
> and as you keep writing an annoying helpless English today and obviously
> do not understand what people are writing, I cannot imagine how you fail
> to see the need to improve that part of your skill set, which as I have
> said, is inordinately important for a good _programmer_.
This implications are breath taking. Because my english is bad I'm not
able to be a good programmer. So at least I know one thing I can
measure, my improvements in english if any. If I'm good in english I
will be a good programmer. That is encourarging.
I would appreciate if you could come up with an equally easy to
understand implication on Lisp programming.
Friedrich
I'm very annoyed by this thread and so it is *very* harsh. Sorry for
bad feelings. Everyone is encouraged to skip it.
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > * Friedrich Dominicus <·····@q-software-solutions.com>
> > | Where is it stated that LOC are useless.
> >
> > Here! Several people have said so. Damnit, can't you _read_,
> >either?
> That were two (you included) seems to be not several ;-)
Here, me too! Or better yet -- lets make a poll or vote so we get a
critical mass for you "make up your mind" at last.
> > | I don't think that the hint on improving my english is anyway related to
> > | the subject.
> >
> > Then you are not really interested in improving your programming
> >skills.
> Interesting conclusion.
Yes, indeed.
> Do you think so? I asked what makes sense to count. LOC isn't the
> answer obviously for you.
I'll try it: I think that line count is no measure for anything except
a weird way of measuring file size. Does that imply that I know a way
to do what you want?
And why are you so eager to count something? Measure your
understanding of the subject now and when you find out the answer to
your question. Then please report your progress and at least I will be
very interested to hear the results.
> I do not believe all I can read in the books and I do try to get
> your opinion. It's clear to me that two have stated clearly that they
> found LOC to be useless.
Lines Of Code not Liters Of Coffee.
> Again that's fine for me. Anyway I do consider some of the books I
> read to be written by people who have a different opinion. I have
> not made up my mind yet.
You don't have to choose the "one truth" here. You have a couple of
opinions at hand -- why don't you just pick out what you agree is
right from all of them and create your own idea of what would be the
best way to do your "count" thing.
And what's more important -- you don't have to make up your
mind. Looks like you are very obsessed with this "premature decision
making" thing (what others are trying to get you away from).
> Just so much while doing a simular thing
> (just counting) in another language I do found some interesting
> numbers. I did not expect too much but the results were very
> interesting.
That's really interesting -- what is so interesting in those results?
(Looks like you are close to what you need -- a formula of how to
derive useful information from Lines Of Code.)
> How to you measure your progress?
Don't you feel your own progress? Why would you want to measure it?
Does your employer pay you for your progress? Do you need something
you can show others and tell how cool you are?
> No I asked what makes sense to count. I understand that LOC is not
> the answer for some of you. What do you suggest (besides improving
> my english)?
Maybe you should first define what a progress is for you? Otherwise I
start to get this feeling that you already have what you want -- make
lines of code per day a measure for progress (for yourself, of
course)?
> > You know, your pathetic display of reading comprehension makes it wholly
> > useless to waste any more lines of _anything_ on you. You aren't going
> > to improve yourself in any relevant way until you really start to listen
> > to what people tell you, which you don't do today at all, so I think you
> > should just go back to the _books_ that "helped" you make up your mind
> > prematurely and just go ahead collect "data" and see if you get
> >anywhere.
> Thanks that is a good suggestion. I do think I will follow it.
Looks like I've spent my time writing this for nothing if you do.
> This implications are breath taking. Because my english is bad I'm not
> able to be a good programmer.
Did you know that becoming better at anything involves learning? Did
you know that learning skills can also be improved? Just why do you
refuse to think about what others are trying to tell you? Is it
because you are afraid to come to conclusion that someone on the
Usenet is smarter than you?
> So at least I know one thing I can measure, my improvements in
> english if any.
Oh, you already know how to measure your progress in English? Is that
method applicable to Lisp code?
> If I'm good in english I will be a good programmer. That is
> encourarging.
There's a difference in "good" and "better".
> I would appreciate if you could come up with an equally easy to
> understand implication on Lisp programming.
That's what you think his implication is and not at all his
implication (as far as my understanding goes).
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87itnc3gfx.fsf@frown.here>
Janis Dzerins <·····@latnet.lv> writes:
> I'm very annoyed by this thread and so it is *very* harsh. Sorry for
> bad feelings. Everyone is encouraged to skip it.
How should I do that? You are annoyed so feel free to skip it
yourself.
> And why are you so eager to count something? Measure your
> understanding of the subject now and when you find out the answer to
> your question. Then please report your progress and at least I will be
> very interested to hear the results.
How can you be annoyed of the thread if you did not read the initial
one. It's for an exercise in those books.
>
> That's really interesting -- what is so interesting in those results?
> (Looks like you are close to what you need -- a formula of how to
> derive useful information from Lines Of Code.)
As written before (annoyed) it took me quite a while to get that
rigth. But it gives me an idea on what thing "could be considered"
usual in that language.
>
> > How to you measure your progress?
>
> Don't you feel your own progress? Why would you want to measure it?
Because I'm curious.
> Does your employer pay you for your progress?
Why do you think I'm an employee? I did state more than once that is
for personal use. I pointed out what I'm trying to do and from where I
got this question. Feel free to look into "A Discipline for Sofware
Engineering" page 750ff.
>Do you need something
> you can show others and tell how cool you are?
Of course, I'm totally dependen on others opinion. I did not learn to
think myself. So I'm in a desperate need for "confirmation"
>
> > No I asked what makes sense to count. I understand that LOC is not
> > the answer for some of you. What do you suggest (besides improving
> > my english)?
>
> Maybe you should first define what a progress is for you?
Progress is for me to have an problem. Starting working on it and
estimating when I will finish. Other progress indicators for me are
- less errors
- better maintainabilty
- well readable software
>Otherwise I
> start to get this feeling that you already have what you want -- make
> lines of code per day a measure for progress (for yourself, of
> course)?
Watts suggest to estimate how many lines you need to solve the
excercises. This should be an indicator on how long you will need to
solve the excercises.
>
> > > You know, your pathetic display of reading comprehension makes it wholly
> > > useless to waste any more lines of _anything_ on you. You aren't going
> > > to improve yourself in any relevant way until you really start to listen
> > > to what people tell you, which you don't do today at all, so I think you
> > > should just go back to the _books_ that "helped" you make up your mind
> > > prematurely and just go ahead collect "data" and see if you get
> > >anywhere.
> > Thanks that is a good suggestion. I do think I will follow it.
>
> Looks like I've spent my time writing this for nothing if you do.
No you did not. You are the third outlineing Lines of code as
useless. Now nobody has stated as clearly that he/she founds it
worthwhile to collect such numbers. So thanks for spending you time on
answering.
>
> > This implications are breath taking. Because my english is bad I'm not
> > able to be a good programmer.
>
> Did you know that becoming better at anything involves learning?
Would you mind not to point out what is obvious?
>Did
> you know that learning skills can also be improved?
see above.
>Just why do you
> refuse to think about what others are trying to tell you?
What have I refused?
>Is it
> because you are afraid to come to conclusion that someone on the
> Usenet is smarter than you?
If I'm around average (optimistic) I know than there should be some
smarter people around on the other hand there will probably some not
so smart people. What about you?
>
> > So at least I know one thing I can measure, my improvements in
> > english if any.
>
> Oh, you already know how to measure your progress in English?
I did not care much till now. But probably I have to.
>Is that
> method applicable to Lisp code?
Maybe, just I would appriciate a method applicable to Common Lisp in
first line.
>
> > If I'm good in english I will be a good programmer. That is
> > encourarging.
>
> There's a difference in "good" and "better".
Please read Erics nice reply.
>
> > I would appreciate if you could come up with an equally easy to
> > understand implication on Lisp programming.
>
> That's what you think his implication is and not at all his
> implication (as far as my understanding goes).
Even better you rellme what I think he thinks This is the art of a
Meta Object Protocol on thoughts. I hope you love such games.
Regards
Friedrich
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | > | What may be a metrics which can help improving yourself to improve
on
> | > | developing software. Maybe you don't bother, but I do.
>
> [...] then _insult_ people
> who don't like that insanely useless measure by saying something so
> stupid as "maybe you don't bother [to improve yourself]".
Try it this way and see if you still find an "insult" to "people":
"maybe you don't bother [*with metrics* as a way of trying to improve your
work practices - but I [Friedrich] do. If you don't think LOC are useful
indicators of quality or productivity, do you know of anything
(quantifiable) that is?]."
You've torn strips off him on a misunderstanding, and then attacked his
comprehension skills.
As for LOC being an "insanely useless" measure, no argument here. ;-)
(Four and counting, frido) ;-)
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <8766jbrfsj.fsf@frown.here>
>
> "maybe you don't bother [*with metrics* as a way of trying to improve your
> work practices - but I [Friedrich] do. If you don't think LOC are useful
> indicators of quality or productivity, do you know of anything
> (quantifiable) that is?]."
Thanks, was more in the intended sense.
>
> As for LOC being an "insanely useless" measure, no argument here. ;-)
> (Four and counting, frido) ;-)
Ok intermediate results (LOC pro: LOC no ;-)
(2:4)
I'm pro and someone else seems to think that counting LOC may make
sense.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> However the problem is that all the offered tools to gather metrics
> assume languages like C, Java, Pascal. So let's say imperative and/or
> objectoriented languages. This languages are less flexible as Lisp is
> and because of the Flexibility I expect finding useful Metrics
> harder. But that does not mean it can not work. If nobody has tried
> before than it's an open question.
You mentioned in another posting that you're looking for a LOC metric
for use with the Personal Software Process. IIRC, the point of the
metric is *not* to give any kind of absolute or
inter-programmer-comparable measure. Rather, the point is to measure for
yourself how much you've done. Apparently, the LOC difference is somehow
correlated to this. Now, let me suggest that in the case of Lisp instead
of lines you count number of parentheses. And I'm not sure myself if I
mean this as a joke. You may try this metric and determine for yourself
how well it correlates with what you're really interested in.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <877l3tuy4c.fsf@frown.here>
········@acm.org (Michael Schuerig) writes:
> Friedrich Dominicus <·····@q-software-solutions.com> wrote:
>
> > However the problem is that all the offered tools to gather metrics
> > assume languages like C, Java, Pascal. So let's say imperative and/or
> > objectoriented languages. This languages are less flexible as Lisp is
> > and because of the Flexibility I expect finding useful Metrics
> > harder. But that does not mean it can not work. If nobody has tried
> > before than it's an open question.
>
> You mentioned in another posting that you're looking for a LOC metric
> for use with the Personal Software Process. IIRC, the point of the
> metric is *not* to give any kind of absolute or
> inter-programmer-comparable measure.
Yes, I tried to point it out as obvious as possible. Anyway I come up
with a modiefied physical line counter first. I'll see how it worked
out ;-)
> Now, let me suggest that in the case of Lisp instead
> of lines you count number of parentheses. And I'm not sure myself if I
> mean this as a joke. You may try this metric and determine for yourself
> how well it correlates with what you're really interested in.
Hm, what braces to count opening? closing? Just the closing braces at
the end of a function, method macro?
Another problem which arises a bit later is Object Loc. How many Locs
per object ...
At least it's interesting ;-)
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
> ...
>Hm, what braces to count opening? closing? Just the closing braces at
>the end of a function, method macro?
count both opening and closing, then divide by 2. just try to avoid
paranthese in string and char literals
hs
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87snmgghtw.fsf@frown.here>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@frown.here>, Friedrich Dominicus wrote:
> > ...
> >Hm, what braces to count opening? closing? Just the closing braces at
> >the end of a function, method macro?
>
> count both opening and closing, then divide by 2. just try to avoid
> paranthese in string and char literals
Have you tried?
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
>> >Hm, what braces to count opening? closing? Just the closing braces at
>> >the end of a function, method macro?
>>
>> count both opening and closing, then divide by 2. just try to avoid
>> paranthese in string and char literals
>
>Have you tried?
no
hs
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
>| I admit that I do think it's hard to come up with metrics for Lisp
>| because of it's flexibility. But I'm quite sure that one can gather
>| different metrics and that the correlate with the LOC somehow. That
>| is a hypotheses! Now how can one find out if it holds or not. You
>| collect and collect and ... and after while you can give it a try.
>| If you found nothing which supports your initial idea. There is
>| probably no relationship. Anyway without trying it won't work, have
>| you?
> What an odd way to look at things. Where did the "hypothesis"
> come from? Where's the rigor in the testing harness that you
> merely imply exists to further your understanding? "From one data
> point, you can extrapolate in all directions", which is why many
> non-scientific hypotheses only provide one data point, usually
> either way the experiment goes.
Indeed.
People _want_ to do quantitative analysis on code, probably because
they have some cool mathematical models that they think might find
interesting patterns.
This is roughly the same basis that technical analysis folk have for
trying to analyze the patterns of stock prices by use of "Elliott
Waves" and Fibonacci Sequences; it turns into glorious quantities of
charts, monthly magazines, which has about as much to do with the way
stock prices behave as does Voodoo Magic.
I've seen a couple books lately that try to have some _actual
theoretical basis_ for doing "object oriented analysis;" that's an
area where there are similarly lots of nifty patterns that people
_love_ to apply to things, but where there's little actual theory to
provide _objective analysis_ that relates the "OO" patterns to the
real world.
In short, there's a whole lot of snake oil here...
--
(reverse (concatenate 'string ········@" "enworbbc"))
<http://www.ntlug.org/~cbbrowne/linux.html>
.you could spend *all day* customizing the title bar. Believe me. I
speak from experience." -- Matt Welsh
On Thu, 18 Jan 2001 ········@hex.net wrote:
> People _want_ to do quantitative analysis on code, probably because
> they have some cool mathematical models that they think might find
> interesting patterns.
>
> This is roughly the same basis that technical analysis folk have for
> trying to analyze the patterns of stock prices by use of "Elliott
> Waves" and Fibonacci Sequences; it turns into glorious quantities of
> charts, monthly magazines, which has about as much to do with the way
> stock prices behave as does Voodoo Magic.
In his book _The Mismeasure of Man_, Stephan J. Gould talks about
biologists loving some particular analytic technique, and using it
everywhere to try to find "significance." Analysis of code strikes me as
a similar situation: we have some abstract ideas about programming systems
(quality, elegance, etc.) that some people would love to quantify, and
which sometimes coincide with certain measurements. Without a theoretical
basis for *why* they should correlate, it's just BS. A point that Gould
brings up in that book is how scientists would actually measure their
metrics incorrectly -- on accident, while trying to be careful -- in such
a way that the metric supportd their presupposition. I think that problem
probably applies here in the reverse (ie, if one wants LOC to correlate
with quality code, one will tend to see larger code bases as higher
quality for no other reason than size).
My other thought on the subject is based on my view of programming as an
intersection of math and litterature (I'm not claiming to be at all unique
in this; but if you don't share this view, you probably won't agree with
me on the following). You *can* measure the mathematical aspects of a
program -- correctness, efficiency, etc. -- and do so precisely. But
trying to measure overall quality, or elegance, or any of its *litterary*
qualities, probably can't work. How do you quantitatively measure the
force with which an argument is advanced in an essay? Or its elegance?
Thomas Francis Burdick <···@u.washington.edu> writes:
> My other thought on the subject is based on my view of programming as an
> intersection of math and litterature (I'm not claiming to be at all unique
> in this; but if you don't share this view, you probably won't agree with
> me on the following). You *can* measure the mathematical aspects of a
> program -- correctness, efficiency, etc. -- and do so precisely. But
> trying to measure overall quality, or elegance, or any of its *litterary*
> qualities, probably can't work. How do you quantitatively measure the
> force with which an argument is advanced in an essay? Or its elegance?
I am in overall agreement with the above, but it did call to mind a
(perhaps facetious) somewhat objective definition of the elegance of an
algorithm, by contrast with a simple algorithm:
Simple algorithm:
Few Lines of Code
Short Correctness Proof
Elegant algotirhm:
Few Lines of Code
Long Correctness Proof
:) :) :)
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> Simple algorithm:
> Few Lines of Code
> Short Correctness Proof
>
> Elegant algotirhm:
> Few Lines of Code
> Long Correctness Proof
No way :-).
Elegant algorithm:
Few Lines of Code
Short Correctness Proof
Elegant *includes* simple. The reason something is elegant includes a clarity
of logic that makes a seemingly complex problem a simple one. Then, since
things are so clear, the proof is obvious.
E.g. bubble sort vs a merge sort. Done right, the merge sort can be expressed
in the appropriate high level steps very succinctly such that the program is
pretty much its own (obvious) inductive proof.
A bubble sort, on the other hand, while seemingly simpler to code, is an order
more inefficient and actually harder to prove, basically because one has to
reason around the unnecessary steps.
See, for example:
"Higher Order Imperative Programming", Aaron Kershenbaum, David Musser,
Alexander Stepanov; Rensselaer Polytechnic Institute Computer Science
Technical Report 88-10, April 1988.
I could not find this one the web, so if you want it go to
http://www.cs.rpi.edu/tr/ and see about asking for a copy via email.
It shows a very elegant merge sort indeed, among a lot of other cool
things. Very nice for lisp programmers especially.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> "Higher Order Imperative Programming", Aaron Kershenbaum, David Musser,
> Alexander Stepanov; Rensselaer Polytechnic Institute Computer Science
> Technical Report 88-10, April 1988.
>
> I could not find this one the web, [...]
http://citeseer.nj.nec.com/kershenbaum88higher.html
You're not using the right search engines ;-)
--
··········@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Jens Kilian <···········@agilent.com> writes:
> Ray Blaak <·····@infomatch.com> writes:
> > I could not find this one the web, [...]
>
> http://citeseer.nj.nec.com/kershenbaum88higher.html
>
> You're not using the right search engines ;-)
Thanks muchly.
This search engine has been a very pleasant surprise for me.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> "Higher Order Imperative Programming", Aaron Kershenbaum, David Musser,
> Alexander Stepanov; Rensselaer Polytechnic Institute Computer Science
> Technical Report 88-10, April 1988.
>
> I could not find this one the web, so if you want it go to
> http://www.cs.rpi.edu/tr/ and see about asking for a copy via email.
>
> It shows a very elegant merge sort indeed, among a lot of other cool
> things. Very nice for lisp programmers especially.
Found it at: ftp://ftp.cs.rpi.edu/pub/stl/hop.ps.Z
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Erik Naggum <····@naggum.net> wrote:
+---------------
| I have found that the more I understand a problem, the fewer lines of
| code I end up with. Just getting something to work usually means writing
| reams of code fast, like a Stephen King novel, but making it maintainable
| and high-quality code that really expresses the ideas well, is like
| writing poetry. Art is taking away.
+---------------
Amen.
In EWD648 "``Why is Software So Expensive'': An Explanation to
the Hardware Designer" [1982 or earlier, scanned copy only at
<URL:http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD648.PDF>],
Dijkstra said:
To this very day we have organizations that measure "programmer
productivity" by the "number of lines of code produced per month".
This number can, indeed, be counted, but they are booking it on
the wrong side of the ledger, for we should talk about "the number
of lines of code spent".
But the earliest version of this sentiment I know of is probably
due to Antoine de Saint-Exupery [1900-1944], oft quoted as saying:
Perfection is attained, not when there is no longer anything
to add, but when there is no longer anything to take away.
-Rob
p.s. Other variations:
"The best part of a design is the part that isn't there."
-- Gordon Bell
"Simplicity, then add lightness"
-- William B. Stout
(Stout Metal Airplane Company, later bought by Ford Motor)
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <873dek6kbi.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | Would like to get you ideas about how to count lines in Common Lisp?
>
> If you count lines and use that to punish or reward people, you will make
> them optimize for the line count, which is a very, very bad thing.
This is obvious and not what is intended. I'm trying to make myself
comfortable with Watt Humphrey PSP process and there you should try to
estimate how "large" you program is likely to get. So it's as personal
as can be ;-)
> I
> really, _really_ hope that is not what you are trying to do. If you want
> good programmers, optimize for creativity, which means: Listen to them.
>
> | (besides the obvious way to just count the physical lines)
>
> Some programmers use lots of blank lines for this purpose. Some line-
> counters then discount all blank lines, which is also wrong. Be sure to
> omit the boiler-plate comments that frequently state such things as
> copyright, license cruft, project management, etc. Some programmers
> think that writing a 48-line comment with starry borders and a fixed set
> of "fields" helps code management, as if they were still writing COBOL
> (although they might never have seen COBOL). All of these techniques are
> basically measures to fool line-counting schemes.
Good points anyway the do not apply here, see above.
>
> | What seems to make sense to count e.g comments?
>
> At least distinguish between comments and documentation strings. The
> latter are _not_ comments.
Interesting idea I come up with a simular scheme. Count the
documentaton String but ignore comments on their own lines. Anyway I
do think I missed #|, so this is not done properly yet.
>
> | My assumptions are (probably totally out of line)
> | - programmers have a "personal" style of programming and over the time
> | I guess calculating LOC (by counting physial lines) and a more
> | complex scheme will yield some relationship (hopefuly with a high
> | degree of certainty ;-)
>
> I have found that the more I understand a problem, the fewer lines of
> code I end up with.
That is again quite interesting, just what happens if you figure out
some things and you think it's worth elaborating on it. Than you add
lines of code but add another abstracted object too.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Would like to get you ideas about how to count lines in Common Lisp?
> (besides the obvious way to just count the physical lines)
I have seen a lot of discussion on this thread in two areas:
1. The purpose of the measurement: You have stated several times that
your own purpose for counting LOC is for personal use. I may have missed
it, but I didn't see anywhere precisely _what_ personal purpose you are
intending this measurement. Are you measuring relative sizes of two
different lisp applications? Or are you measuring progress from one
point in your coding effort to the next? The answer to these questions
and perhaps more must be known if we are to help you determine a good
method for a metric.
2. The relevancy of LOC counts: Many people have stated that LOC
count is irrelevant. I disagree; LOC counting can be _harmful_! I know
that your purposes are personal, but if my paycheck were based on the
number of lines of code I wrote, I would be paying my employer most of
the time, rather than being paid! I.e. my job entails maintenance of a
large body of code which includes _removing_ LOC due to simplifications
and rewriting. Thus, in my circumstance, LOC count is sometimes an
inverse indicator of work performed. Let me explain why I believe this
is especially true in Common Lisp programs:
a. You may have heard that the majority of programming effort is not
in initial coding of the application; there is design and maintenance
as well. And from at least one source, the maintenance portion takes
80% of the time for a reasonably long-lived application. Design takes
up a large portion of the remainder, and coding (thus LOC) is a
relatively small portion of the work that goes in to an application.
b. Maintenance (bug fixing, feature enhancing) can be done by always
writing new code, or it can be done by expanding algorithms and rewriting
older code. In languages that are considered "write only", the former
tends to be needed in order not to break existing functionality. Of course,
unreadable code can be written in any language, so it is really the
application itself that becomes write-only. However, CL makes it much
easier to write readable code, so I will assume that the basic application
may be understood. Thus, adding a simple feature or fixing a bug is
reduced to finding that portion of the code which is understood to be
the offending portion, and either adding some lines, removing some lines,
or replacing some lines (rather than always adding lines of code, sometimes
covering bugs rather than removing them). When portions of the code are
incomprehensible or less efficient, the whole section might be replaced
to fix the bug or add the feature, and usually does result in smaller
code in many ways. [I must stress the importance of a good regression test
suite with this kind of programming, otherwise it will simply not work].
c. A programmer tends to make decisions about what changes to make
based on all of the requirements he/she knows about. If there is an
awareness of a LOC count, then the tendency will _not_ be to reduce the
size or complexity of a program, because the change would eventually
be measured. Since I strongly believe that simplicity is a good
thing, this tendency becomes a bad thing. Now, it is in fact easy to
measure my LOC counts, and the LOC count deltas of any of the other
programmers in my company, because of the source-control system we use.
However, none of us tend to pay attention to this metric, and thus I
am free to remove code that is useless and to keep our system simple.
Because of this, if we were to look at the difference in code created
to code removed, my gut tells me that I have removed more than I have
added over the years.
> What seems to make sense to count e.g comments?
Let me throw another concept in: Count features and defects, not lines.
These are both much harder to count, but track much more closely to
a programmer's productivity than lines of code.
But then again, you haven't told us whether you are interested in
measuring productivity, have you? ...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87ely0hxcc.fsf@frown.here>
Duane Rettig <·····@franz.com> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Would like to get you ideas about how to count lines in Common Lisp?
> > (besides the obvious way to just count the physical lines)
>
> I have seen a lot of discussion on this thread in two areas:
>
> 1. The purpose of the measurement: You have stated several times that
> your own purpose for counting LOC is for personal use. I may have missed
> it, but I didn't see anywhere precisely _what_ personal purpose you are
> intending this measurement. Are you measuring relative sizes of two
> different lisp applications? Or are you measuring progress from one
> point in your coding effort to the next? The answer to these questions
> and perhaps more must be known if we are to help you determine a good
> method for a metric.
Watt Humphrey asked the reader of his books to count such thing for
planning purposes. I cite from chapter 5 page 97 : "The principal
reason you should estimate the size of a software product is to help
you to plan the product's development. The quality of a sofware
development plan, in turn, generally depens on the quality of the size
estimates..."
>
> 2. The relevancy of LOC counts: Many people have stated that LOC
> count is irrelevant. I disagree; LOC counting can be _harmful_! I know
> that your purposes are personal, but if my paycheck were based on the
> number of lines of code I wrote,
I admit that and I hopes I stated it clearly enough that no-one should
be judged by that counting.
>I would be paying my employer most of
> the time, rather than being paid! I.e. my job entails maintenance of a
> large body of code which includes _removing_ LOC due to simplifications
> and rewriting.
For this Watts suggest in his book about the PSP not just to count the
written Lines of code but too the modified and deleted lines (Chapter
4, page 85ff)
>Thus, in my circumstance, LOC count is sometimes an
> inverse indicator of work performed. Let me explain why I believe this
> is especially true in Common Lisp programs:
>
> a. You may have heard that the majority of programming effort is not
> in initial coding of the application; there is design and maintenance
> as well. And from at least one source, the maintenance portion takes
> 80% of the time for a reasonably long-lived application. Design takes
> up a large portion of the remainder, and coding (thus LOC) is a
> relatively small portion of the work that goes in to an application.
I agree fully, but do not see why it just should hold for Common
Lisp, this figures can be found in nearly any book about Software
Maintenance and they are surely not specifically written with Common
Lisp as implementation language.
>
> b. Maintenance (bug fixing, feature enhancing) can be done by always
> writing new code, or it can be done by expanding algorithms and rewriting
> older code. In languages that are considered "write only", the former
> tends to be needed in order not to break existing functionality. Of course,
> unreadable code can be written in any language, so it is really the
> application itself that becomes write-only.
I could not agree more.
> However, CL makes it much
> easier to write readable code, so I will assume that the basic application
> may be understood.
That is IMHO not a privilege from Common Lisp ;-)
>Thus, adding a simple feature or fixing a bug is
> reduced to finding that portion of the code which is understood to be
> the offending portion, and either adding some lines, removing some lines,
> or replacing some lines (rather than always adding lines of code, sometimes
> covering bugs rather than removing them). When portions of the code are
> incomprehensible or less efficient, the whole section might be replaced
> to fix the bug or add the feature, and usually does result in smaller
> code in many ways. [I must stress the importance of a good regression test
> suite with this kind of programming, otherwise it will simply not
> work].
Yes and this now has a nice new name "Refactoring" ;-) By chance 10 cm
left of my left hand lies a book "Refactoring improving the design of
existing code" and the author states as clearly as you "You do need an
excellent test suite".
>
> c. A programmer tends to make decisions about what changes to make
> based on all of the requirements he/she knows about. If there is an
> awareness of a LOC count, then the tendency will _not_ be to reduce the
> size or complexity of a program, because the change would eventually
> be measured.
Just one thing, the LOC count is not considered to be published to
anyone else but yourself.
>Since I strongly believe that simplicity is a good
> thing, this tendency becomes a bad thing. Now, it is in fact easy to
> measure my LOC counts, and the LOC count deltas of any of the other
> programmers in my company, because of the source-control system we use.
> However, none of us tend to pay attention to this metric, and thus I
> am free to remove code that is useless and to keep our system simple.
> Because of this, if we were to look at the difference in code created
> to code removed, my gut tells me that I have removed more than I have
> added over the years.
May I cite from Watts Book? (Chapter 4.6 page 85 ff)
"When you develop or enhance programs, you need some way to track all
the additions, deletions, and changes."
Then he illustrates with an example of what problems one might
encounter.
>
> > What seems to make sense to count e.g comments?
>
> Let me throw another concept in: Count features and defects, not lines.
> These are both much harder to count, but track much more closely to
> a programmer's productivity than lines of code.
This is another part of learning the PSP. And you anyway should keep a
time track on how many time you spend on which task.
>
> But then again, you haven't told us whether you are interested in
> measuring productivity, have you? ...
As I understand the PSP is a personal guide and should help each
individual programmer to improve his way of developing software. So in
some wider sense I do think it can be seen as a "personal productivity
measurement". That is how I see it. I do think this books is worth
reading and it's IMHO too worth to take the time to do the
excercises.
Thanks for sharing your thoughts
Friedrich
> From: Duane Rettig <·····@franz.com>
> 2. The relevancy of LOC counts: Many people have stated that LOC
> count is irrelevant. I disagree; LOC counting can be _harmful_! I know
> that your purposes are personal, but if my paycheck were based on the
> number of lines of code I wrote, I would be paying my employer most of
> the time, rather than being paid!
I have similar experiences. I once spent a while reducing a 15k line
Lisp program that didn't work into a 7k one that did. And got paid
for it, too.
One of the main reasons why the 15k version (written by someone
else) did not work was the dreaded disease known as cut'n'paste
programming, and this was also why it was relatively straightforward
to cut down in size. It was not a pleasant experience, however.
--
*** Ola Rinta-Koski Espoo, FINLAND
***
There's a vas deferens between the epididymis and the ampulla.
Friedrich Dominicus wrote:
>
> Would like to get you ideas about how to count lines in Common Lisp?
> (besides the obvious way to just count the physical lines)
>
> What seems to make sense to count e.g comments?
I think if you read literature on LOC, it is defined to not include lines of all comments or blank lines. I see no reason why this would be different in Lisp.
>
> If I had
>
> (defun foo (bar)
> " comment for Foo maybe
> over more lines and more
> and more ..."
> (bla bar) ; some comment
> ;; some other comment
> (other-lisp))
>
> Is it two lines of code (bla .. (other
> How many comments? One, two, three or more?
>
> Of what about
> (and foo bar baz
> (< foo bar baz)
> (or w1 w2 w3))
>
> of course this is not really a good example but how to "calculate" the
> diference between "simple" forms like
>
> (foo bar)
>
> and complex forms?
>
> It would be too interesting of what you think seems to be a sort or
> measurement to calculate a size of a project.
>
> My assumptions are (probably totally out of line)
> - programmers have a "personal" style of programming and over the time
> I guess calculating LOC (by counting physial lines) and a more
> complex scheme will yield some relationship (hopefuly with a high
> degree of certainty ;-)
> - it's hard to tell how all the defxxxxx stuff influences the result,
> again it may depend on the programmer and how he/she uses Macros and
> other special forms
> - it seems to make sense to count comments separatly (very intensively
> commented functions may point to a "complex" algorithm, which probably
> can be improved)
> - other things which may be worth counting separatly is the ratio of
> Functions/Macros, generic functions, "usual functions" and the like
> - it seems to me that because of Lisps flexibility it will be harder to come
> up with such things as e.g in "single" paradigm languages (e.g like C,
> even Eiffel etc)
> - it seems to be especially difficult to grade the "influence" of
> macros which probably are used to write a lot of lines
Typical use for LOC include defect measurement i.e. in units of defects/kloc, and estimating software development projects. So as long as you are consistent in
your methodology, it doesn't matter if you expand macros before counting LOC or not because the absolute value of LOC isn't important, it is only used on a
relative basis.
For example, if lisp projects I have managed with my team of 5 developers in the past have produced an average of 5 KLOC/month of designed, debugged, delivered
code, and I have a new task I estimate to be 100 KLOC, all things being equal, I can estimate about 20 months of work.
If our last delivered product had 1 defect per KLOC and our customers were not complaining about its instability, then when our new product gets to the point
where we have only 1 defect per KLOC, then we can ship.
In neither of these examples does it really matter *how* I counted LOCs, as long as I do it the same way every time.
"Christopher J. Vogt" <····@computer.org> writes:
> If our last delivered product had 1 defect per KLOC and our
> customers were not complaining about its instability, then when our
> new product gets to the point where we have only 1 defect per KLOC,
> then we can ship.
I think this is misleading since it suggests that this is really the
criterion. Suppose, as happened once at Symbolics, the defect was that
compiling special variables in a LAMBDA expression yielded a lexical
binding instead of a special binding. Would you say that if there weren't
too many other problems, you should just go with this? (People got mad at
me for finding this bug the day before a ship date, but it did hold up the
release a day or two.)
Personally, I'm ok with what you say as an auxiliary or confirming metric--a
sort of "blunder control" or "idiot check". But I think that most serious
products have a list of "must work" scenarios and if those are not met,
regardless of defects per kloc, the product should not ship. Moreover, if
those ARE met, regardless of defects per kloc, I bet most companies will ship
as well since I doubt they can afford to holdup a release based on a
statistical anomaly. So I think it's not necessarily intentionally
disingenuous of you, yet still you're kidding yourself, if you really think
that defects per kloc is what is truly gating release by anyone who really
understands their product.
This may be a good low-grade metric for assessing where dollars should be
invested in a company to beef up product quality, all other things being
equal. I'm not saying it has no value. I'm just saying its primary value
is not "suitability for release".
JMO.
In article <···············@world.std.com>, Kent M Pitman wrote:
> ...
>I think this is misleading since it suggests that this is really the
>criterion. Suppose, as happened once at Symbolics, the defect was that
>compiling special variables in a LAMBDA expression yielded a lexical
>binding instead of a special binding. Would you say that if there weren't
>too many other problems, you should just go with this? (People got mad at
>me for finding this bug the day before a ship date, but it did hold up the
>release a day or two.)
imo, this example shows up the madness of the quantitative measurements in
a mainly design and analysis driven environment. the concept of quantitative
measurements makes sense in a pure production environment, where a finished
design is realise gazillion times. it doesn't make (imo) any sense in an
environment where the work is done once.
> ...
hs
Kent M Pitman wrote:
>
> "Christopher J. Vogt" <····@computer.org> writes:
>
> > If our last delivered product had 1 defect per KLOC and our
> > customers were not complaining about its instability, then when our
> > new product gets to the point where we have only 1 defect per KLOC,
> > then we can ship.
>
> I think this is misleading since it suggests that this is really the
> criterion. Suppose, as happened once at Symbolics, the defect was that
> compiling special variables in a LAMBDA expression yielded a lexical
> binding instead of a special binding. Would you say that if there weren't
> too many other problems, you should just go with this? (People got mad at
> me for finding this bug the day before a ship date, but it did hold up the
> release a day or two.)
Of course there are show stoppers that you don't ship unless they get fixed. I wasn't trying to write a complete instructional text on software readiness, just
trying to give examples of why it doesn't matter what gets counted in LOC as long as it is reasonable and consistent.
> Personally, I'm ok with what you say as an auxiliary or confirming metric--a
> sort of "blunder control" or "idiot check". But I think that most serious
> products have a list of "must work" scenarios and if those are not met,
> regardless of defects per kloc, the product should not ship. Moreover, if
> those ARE met, regardless of defects per kloc, I bet most companies will ship
> as well since I doubt they can afford to holdup a release based on a
> statistical anomaly. So I think it's not necessarily intentionally
> disingenuous of you, yet still you're kidding yourself, if you really think
> that defects per kloc is what is truly gating release by anyone who really
> understands their product.
>
> This may be a good low-grade metric for assessing where dollars should be
> invested in a company to beef up product quality, all other things being
> equal. I'm not saying it has no value. I'm just saying its primary value
> is not "suitability for release".
It is just one commonly used metric, I didn't mean to imply it was the only one, or even the best one, just that it is commonly used.
"Christopher J. Vogt" <····@computer.org> writes:
> Of course there are show stoppers that you don't ship unless they
> get fixed. I wasn't trying to write a complete instructional text
> on software readiness, just trying to give examples of why it
> doesn't matter what gets counted in LOC as long as it is reasonable
> and consistent.
My point was that if it's not a necessary condition and it's not a
sufficient condition, then it's probably not a condition. It's just
a feel-good thing. And I think that defects per kloc is just that.
It's not sufficient to release your code just because the defect
level is low, regardless of other things. Nor is it probably necessary
to get the defect level below a certain level before release either,
provided certain mission-critical tasks are in order. Therefore, I claim,
it's only an imaginary criterion made up for show ... in most cases.
Surely there are exceptions, but I bet most involve poeple who don't
understand their product and don't have a list of REAL necessary and
sufficient conditions, and are just substituting this kind of thing for
want of something else that "looks scientific/objective".
It's one thing if defects are of a homogenous nature. e.g., if one measures
the rate of errors in a hardware fabrication plant that is doing the same
operation over and over but sometimes screwing it up for physical reasons.
The effect of selling one bad chip is well-understood in terms of cost, and
the liability for having done so is managed in the user license. Having 10
is approximately ten times the cost of 1. But bugs are not substitutable
for one another, since some code is seldom-used, some is often-used, some is
often-used by few users, and some is often-used by many users. If you measure
only bugs/line, you lose the other axes of this multidimensional space and
necessarily screw things up. The space might be very tall but not very wide,
or very wide but not very tall. Looking at only one axis will not tell you
the volume. I'm not really much of a mathemetician, but it would seem to me
that just a simple view of geometry would tell you there's something seriously
wrong with this as a predictive approach, even without getting as far as
a statistical analysis (which I'm definitely no good at).
From: Tim Bradshaw
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <ey3itnbcwka.fsf@cley.com>
* Kent M Pitman wrote:
> It's one thing if defects are of a homogenous nature. e.g., if one measures
> the rate of errors in a hardware fabrication plant that is doing the same
> operation over and over but sometimes screwing it up for physical reasons.
> The effect of selling one bad chip is well-understood in terms of cost, and
> the liability for having done so is managed in the user license. Having 10
> is approximately ten times the cost of 1. But bugs are not substitutable
> for one another, since some code is seldom-used, some is often-used, some is
> often-used by few users, and some is often-used by many users.
I think the bug analogy for faulty chips would be if sometimes a
faulty chip would explode, usually just killing the user but
occasionally taking out the whole block.
--tim
"Christopher J. Vogt" <····@computer.org> writes:
> It is just one commonly used metric, I didn't mean to imply it was
> the only one, or even the best one, just that it is commonly used.
I think it was Erik in another message who pointed out the irony of
counting uses while discussing goodness/badness of something. About
the only piece of information that telling us it's commonly used adds
is, IMO, the conditional conclusion that "if the use of defects/kloc
is a priori a bad idea, then knowing it's commonly used means there is
a lot of badly QA'd stuff out there". Or do you mean to imply that
perhaps its common use implies we're missing something in our analysis..
Kent M Pitman wrote:
>
> "Christopher J. Vogt" <····@computer.org> writes:
>
> > It is just one commonly used metric, I didn't mean to imply it was
> > the only one, or even the best one, just that it is commonly used.
>
> I think it was Erik in another message who pointed out the irony of
> counting uses while discussing goodness/badness of something. About
> the only piece of information that telling us it's commonly used adds
> is, IMO, the conditional conclusion that "if the use of defects/kloc
> is a priori a bad idea, then knowing it's commonly used means there is
> a lot of badly QA'd stuff out there". Or do you mean to imply that
> perhaps its common use implies we're missing something in our analysis..
If something is commonly used I assume it must be useful to those who use it, so I guess I would be implying that defects/KLOC is useful to those who use it.
One can say "I don't find defects/KLOC to be useful." but it would be inaccurate to say "defects/KLOC isn't useful."
I don't find C++ useful, but obviously lots of other people do find it useful, so it would be incorrect for me to say "C++ isn't useful". I just can't see
"usefulness" in terms of right/wrong or good/bad.
In article <·················@computer.org>, Christopher J. Vogt wrote:
>Kent M Pitman wrote:
> ...
>If something is commonly used I assume it must be useful to those who use it,
> so I guess I would be implying that defects/KLOC is useful to those who use
> it.
in a cynic view: it is useful by giving some people the warm fuzzy feeling to
have measured something, regardless how otherwise useful the measurement is.
as somebody (i think it was kent pitman) has pointed out already, a low
defect/kloc won't do you any good when the few defects are showstoppers. otoh,
i can imagine situations where a high level of defects/kloc makes still an
acceptable product: assume all those defects are in hardly ever used areas,
but the code fixes quite common complaints (showstopper bugs in previous
releases, missing functionality etc). in this case releasing the code with
good documentation andadvisories could be an option (at least for beta)
hs
"Christopher J. Vogt" <····@computer.org> writes:
> One can say "I don't find defects/KLOC to be useful." but it would
> be inaccurate to say "defects/KLOC isn't useful."
Well, but you aren't specifying for what purpose. If your purpose is
merely to create a smokescreen of deniability when someone asks if you
had an acceptance criterion, that's "useful for avoiding blame". If
your purpose is to assure quality of a system, that's a different thing.
People here (myself among them) seem to be arguing (and, to my biased mind,
effectively) that while it may be useful in the Dilbert-esque sence of
avoiding blame and appearing to be doing something prdocutive, it's not
in fact improving quality because the space not being homogenous means that
a few multiplies don't accomodate the structural issues.
I've never been one for proofs, but it seems like it should be possible
to prove (as was done for perceptrons) that there are limits to what you can
use this for, and that some of the things you want to recognize are
structurally beyond the limits of this technique. Maybe I'm wrong on this
point, but it just has that feel...
"Christopher J. Vogt" <····@computer.org> writes:
> Kent M Pitman wrote:
> >
> > "Christopher J. Vogt" <····@computer.org> writes:
> >
> > > It is just one commonly used metric, I didn't mean to imply it was
> > > the only one, or even the best one, just that it is commonly used.
> >
> > I think it was Erik in another message who pointed out the irony of
> > counting uses while discussing goodness/badness of something. About
> > the only piece of information that telling us it's commonly used adds
> > is, IMO, the conditional conclusion that "if the use of defects/kloc
> > is a priori a bad idea, then knowing it's commonly used means there is
> > a lot of badly QA'd stuff out there". Or do you mean to imply that
> > perhaps its common use implies we're missing something in our analysis..
>
> If something is commonly used I assume it must be useful to those
> who use it, so I guess I would be implying that defects/KLOC is
> useful to those who use it.
oh it is useful. you have say *something* to a pointy-haired boss.
think of dilbert here.
i remember a status meeting where i said i had a problem in my C
program where some pointer got lost and blew a hole in my data. the
boss said "how long will that bug take to fix?" i replied, "oh, it
could be fixed within 5 minutes of me leaving this meeting or it might
take a month to find. i just don't know" while true, this answer was
deemed "unacceptible." i had to lie and say "3 days" just to get out
of the meeting.
i think lines of code may be in this bucket. it can let you be
released from a stupid meeting. i don't think it has much more worth
than that.
> One can say "I don't find defects/KLOC to be useful." but it would be inaccurate to say "defects/KLOC isn't useful."
>
> I don't find C++ useful, but obviously lots of other people do find it useful, so it would be incorrect for me to say "C++ isn't useful". I just can't see
> "usefulness" in terms of right/wrong or good/bad.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
"Christopher J. Vogt" <····@computer.org> writes:
> In neither of these examples does it really matter *how* I counted
> LOCs, as long as I do it the same way every time.
AND I write comparable code every time. Most successful applications
of KLOC-based estimation techniques seem to be found in areas where
applications don't differ wildly, like e.g. many business
applications, or certain areas of scientific applications.
I'd contend that even the same programmer/team will find that their
LOC-based productivity will differ wildly once the applications start
to vary wildly in complexity, or once they reach a certain complexity
level where hard thinking is required most of the time (i.e. little
run-of-the-mill coding, much need for research).
The original poster is just looking for a LOC counting standard for
use in the PSP, so at least for the training exercises this probably
shouldn't matter, but it is my contention that once he starts to use
the PSP in real-life personal projects, he will see such effects,
unless the projects are fairly well-behaved w.r.t. KLOCs.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <8766jchwux.fsf@frown.here>
"Pierre R. Mai" <····@acm.org> writes:
>
> I'd contend that even the same programmer/team will find that their
> LOC-based productivity will differ wildly once the applications start
> to vary wildly in complexity, or once they reach a certain complexity
> level where hard thinking is required most of the time (i.e. little
> run-of-the-mill coding, much need for research).
You wrote "contend" which means you are not sure, but you think it is
that way. So without trying you hardly will find out...
>
> The original poster is just looking for a LOC counting standard for
> use in the PSP, so at least for the training exercises this probably
> shouldn't matter, but it is my contention that once he starts to use
> the PSP in real-life personal projects, he will see such effects,
> unless the projects are fairly well-behaved w.r.t. KLOCs.
Because it's the PSP I can stress whatever I like most. And the most
important thing for me while programming is to make is as readable and
understandable for the latter maintenance. So I do think that my Locs
are "well behaved"
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> "Pierre R. Mai" <····@acm.org> writes:
>
> >
> > I'd contend that even the same programmer/team will find that their
> > LOC-based productivity will differ wildly once the applications start
> > to vary wildly in complexity, or once they reach a certain complexity
> > level where hard thinking is required most of the time (i.e. little
> > run-of-the-mill coding, much need for research).
>
> You wrote "contend" which means you are not sure, but you think it is
> that way. So without trying you hardly will find out...
I wrote "contend" because I have not invested the necessary millions
to test this hypothesis in rigorous experiments to the level of
statistical significance. The opinions expressed in my posting didn't
pop out of my head just in time to post them to c.l.l., as you seem to
imply.
I'm quite aware of the work of the Software Engineering Institute in
general, and of Watts S. Humphrey in particular. Furthermore I've
worked in environments where KLOC-based metrics where collected (and
used as they are intended, i.e. as process metrics, and not as
programmer metrics), and I do still collect certain KLOC-based metrics
in some of the projects I'm involved with.
Based on this experience, I've observed the effects of that what I
contend. I've also observed this effect in my own, personal work,
time and time again. You will also find that all half-serious
KLOC-based estimating techniques (the classic COCOMO[1] is an example
of this) do in fact contain correction factors taking into account
software complexity.
In the COCOMO, product complexity is the single factor with the highest
range (0.70 - 1.65), and if we include the other two product factors
(reliability at 0.75-1.40 and size of database at 0.94-1.16), we get a
range of 0.48-2.67, i.e. the most complex product will take 5.56 times
more effort than the least complex product. This doesn't even take
into account the influence of hardware-related attributes, like
reaction time requirements.
Only the programmer-related attributes, which taken all together can
vary from 0.38 to 3.03, do exceed the product complexity related
factors.
IMHO the problem with all of this is that it is often very difficult
to estimate program complexity before-hand, and that even very
localised complexity can have very large effects. It is not uncommon
to have a programmer spend more than a month on a single function.
And then you can have a programmer write, debug and test whole modules
in less than a month.
> > The original poster is just looking for a LOC counting standard for
> > use in the PSP, so at least for the training exercises this probably
> > shouldn't matter, but it is my contention that once he starts to use
> > the PSP in real-life personal projects, he will see such effects,
> > unless the projects are fairly well-behaved w.r.t. KLOCs.
> Because it's the PSP I can stress whatever I like most. And the most
> important thing for me while programming is to make is as readable and
> understandable for the latter maintenance. So I do think that my Locs
> are "well behaved"
You have not understood a single word I have said, have you? My
contention is that KLOC-based metrics will only work for projects
where KLOCs are for the most part of comparable complexity. This is
totally unrelated to how readable or unreadable the code you produce
is. It is only related to the stuff your programs do. If most of
your code and projects are very similar to each other (e.g. you write
mostly data-entry and reporting applications with fairly well
understood complexity and structure[2]), then KLOC-based metrics will
most likely work better than if you write code that is wildly varying
in complexity, with characteristics that are by their very nature not
that well understood until the "end" of the project.
To put this all into some sort of broader perspective: The processes
and metrics used in "software engineering" are mostly loaned from the
very successful field of quality assurance in production plants. The
main problem (as another poster has already pointed out) with
transferring these techniques to the field of software is the fact that
all the metrics are based on statistical methods, which by their very
nature only work when there are many comparable things that can be
measured: Like e.g. washing machines (or their components), where you
have > 3000 machines per day, all alike, all based on the same design,
all built in the same way, that you can measure, and compare.
Software by its very nature isn't like this at all, so the basis of
software engineering processes based on these statistical measurements
seems suspect at best. All the more so, the farther your software
"products" stray from the mass-production ideal (many, all alike) and
enter the art arena (few, all different).
But it really does seem like you won't listen to any of this, so go
ahead, give the PSP[3] a try, and see for yourself the real-world
effects. Since any good process will guide you to reflect on what you
do, it will always improve your work in one way or another.
Regs, Pierre.
Footnotes:
[1] Barry W. Boehm: Software Engineering Economics, Prentice Hall,
Englewood Cliffs, NJ, 1981.
[2] Applications of this sort are what many studies on software
metrics seem to have studied. This can also be seen in the terms
that some metrics like function points use for program
components.
[3] Be sure to use the following book, and Boehm in addition, though:
Watts S. Humphrey: A Discipline for Software Engineering, Addison
Wesley, Reading, MA, 1995.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87y9w7zc2d.fsf@frown.here>
"Pierre R. Mai" <····@acm.org> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > "Pierre R. Mai" <····@acm.org> writes:
> >
> > >
> > > I'd contend that even the same programmer/team will find that their
> > > LOC-based productivity will differ wildly once the applications start
> > > to vary wildly in complexity, or once they reach a certain complexity
> > > level where hard thinking is required most of the time (i.e. little
> > > run-of-the-mill coding, much need for research).
> >
> > You wrote "contend" which means you are not sure, but you think it is
> > that way. So without trying you hardly will find out...
>
> I wrote "contend" because I have not invested the necessary millions
> to test this hypothesis in rigorous experiments to the level of
> statistical significance. The opinions expressed in my posting didn't
> pop out of my head just in time to post them to c.l.l., as you seem to
> imply.
Sorry, I was thinking you were so carefully, and were expressing a
opinion not backed by many data. I misunderstood that.
>
> Based on this experience, I've observed the effects of that what I
> contend. I've also observed this effect in my own, personal work,
> time and time again. You will also find that all half-serious
> KLOC-based estimating techniques (the classic COCOMO[1] is an example
> of this) do in fact contain correction factors taking into account
> software complexity.
>
> In the COCOMO, product complexity is the single factor with the highest
> range (0.70 - 1.65), and if we include the other two product factors
> (reliability at 0.75-1.40 and size of database at 0.94-1.16), we get a
> range of 0.48-2.67, i.e. the most complex product will take 5.56 times
> more effort than the least complex product. This doesn't even take
> into account the influence of hardware-related attributes, like
> reaction time requirements.
The same holds for function points IIRC.
>
> Only the programmer-related attributes, which taken all together can
> vary from 0.38 to 3.03, do exceed the product complexity related
> factors.
How have thos programmer-related attributes been measured.
>
> IMHO the problem with all of this is that it is often very difficult
> to estimate program complexity before-hand, and that even very
> localised complexity can have very large effects. It is not uncommon
> to have a programmer spend more than a month on a single function.
> And then you can have a programmer write, debug and test whole modules
> in less than a month.
You're rigth.
>
> > > The original poster is just looking for a LOC counting standard for
> > > use in the PSP, so at least for the training exercises this probably
> > > shouldn't matter, but it is my contention that once he starts to use
> > > the PSP in real-life personal projects, he will see such effects,
> > > unless the projects are fairly well-behaved w.r.t. KLOCs.
> > Because it's the PSP I can stress whatever I like most. And the most
> > important thing for me while programming is to make is as readable and
> > understandable for the latter maintenance. So I do think that my Locs
> > are "well behaved"
>
> You have not understood a single word I have said, have you?
I do think that I understand even more than one word. But I missed
some points obviously otherwise you would not ask.
> My
> contention is that KLOC-based metrics will only work for projects
> where KLOCs are for the most part of comparable complexity.
That holds for the excercises IMHO.
> This is
> totally unrelated to how readable or unreadable the code you produce
> is. It is only related to the stuff your programs do. If most of
> your code and projects are very similar to each other (e.g. you write
> mostly data-entry and reporting applications with fairly well
> understood complexity and structure[2]), then KLOC-based metrics will
> most likely work better than if you write code that is wildly varying
> in complexity, with characteristics that are by their very nature not
> that well understood until the "end" of the project.
Very good points. But for the excercises this seems to hold.
>
> To put this all into some sort of broader perspective: The processes
> and metrics used in "software engineering" are mostly loaned from the
> very successful field of quality assurance in production plants. The
> main problem (as another poster has already pointed out) with
> transferring these techniques to the field of software is the fact that
> all the metrics are based on statistical methods, which by their very
> nature only work when there are many comparable things that can be
> measured: Like e.g. washing machines (or their components), where you
> have > 3000 machines per day, all alike, all based on the same design,
> all built in the same way, that you can measure, and compare.
If I understand you correctly than you can just use statistical
methods on large simular "projects". Now I just assume you are working
in the "business sector" and have written some packages for accounting
in this case you would say the complexity is still simular and so
counting is useful. Do I understand that correctly?
>
> Software by its very nature isn't like this at all, so the basis of
> software engineering processes based on these statistical measurements
> seems suspect at best. All the more so, the farther your software
> "products" stray from the mass-production ideal (many, all alike) and
> enter the art arena (few, all different).
This is a very good point. Don't you think that even very different
software packages share some common things?
>
> But it really does seem like you won't listen to any of this, so go
> ahead, give the PSP[3] a try, and see for yourself the real-world
> effects.
I will listen, but will proceed learning the PSP and part of it is
figuring out a way counting LOC.
> Since any good process will guide you to reflect on what you
> do, it will always improve your work in one way or another.
That is probably what all this things are about.
>
> [3] Be sure to use the following book, and Boehm in addition, though:
> Watts S. Humphrey: A Discipline for Software Engineering, Addison
> Wesley, Reading, MA, 1995.
Of course I have this book. Could you explaind what the Boehm book is
about.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > Only the programmer-related attributes, which taken all together can
> > vary from 0.38 to 3.03, do exceed the product complexity related
> > factors.
>
> How have thos programmer-related attributes been measured.
They have not been measured, they were, like all factors in the
COCOMO, "invented" as part of the estimating framework. They are
backed by the analysis of projects that went into the COCOMO. Like
all estimating frameworks, this is just another try to find a simple
function that can be fitted to the existing metrics.
> > My
> > contention is that KLOC-based metrics will only work for projects
> > where KLOCs are for the most part of comparable complexity.
> That holds for the excercises IMHO.
As I said in my original posting, I agree that this isn't a problem
with the exercises (but that's hardly interesting, is it?). OTOH the
exercises are so far removed from real projects, and furthermore are
so small, that KLOC-based metrics will probably not really work,
either. The exercises are just meant to introduce you to the
mechanics of metric gathering, and process-based development, and get
you used to collecting all this stuff in the first place. I don't
think anyone seriously believes the metrics gathered as part of this
do constitute any really valid measurements.
> If I understand you correctly than you can just use statistical
> methods on large simular "projects". Now I just assume you are working
> in the "business sector" and have written some packages for accounting
> in this case you would say the complexity is still simular and so
> counting is useful. Do I understand that correctly?
In a previous life, I have written business data-entry and reporting
applications, and found KLOCs to behave somewhat rationally. BUT this
is mostly due to the fact that this kind of programming is >95% rote
exercise, where most of the code could probably be much better
generated using advanced code generators. I mean what's involved in
"designing" and coding the code that underlies most input masks? The
difficult part is not coding that stuff, it is communicating with
clients to get the correct specifications in place. Once that's done,
most of the ensuing work involves little surprising elements, and most
code is comparable in complexity to other code in the same and other
projects.
Nowadays I work in a fairly different field, namely that of logistics
and manufacturing simulations. There you don't write 4 applications a
year, all similar. You write one framework for >10 years, and at
least 50% of the code is fairly non-trivial. You write maybe 4
"applications" a year, but each of those is fairly different, because
the common parts have already been successfully factored out to the
framework. KLOC-based productivity measurements give highly-varying
KLOC/MM numbers.
> > Software by its very nature isn't like this at all, so the basis of
> > software engineering processes based on these statistical measurements
> > seems suspect at best. All the more so, the farther your software
> > "products" stray from the mass-production ideal (many, all alike) and
> > enter the art arena (few, all different).
>
> This is a very good point. Don't you think that even very different
> software packages share some common things?
Well washing machines and planes also share some common things. Does
that mean that their production processes and quality assurance yield
comparable numbers? Again QA measurements work because you have
thousands of "identical" things that you can measure. Just because
all of them contain M5 screws, measuring a washing machine today, and
an A320 tomorrow, and an MCC Smart the next day won't give you any
useful insight. Maybe you can find ways to measure only the similar
parts, and gain useful insights from that, but that's hardly what
KLOC-based software-metrics do.
> > Since any good process will guide you to reflect on what you
> > do, it will always improve your work in one way or another.
> That is probably what all this things are about.
In a way yes, that's what good processes are about. But let me
suggest that you make other observations on your code and your work,
and note them down in a notebook while working. Analyse them later.
Find out in what areas your weaknesses lie, and try to improve those.
Observe, analyse, again. Good qualitative measurements are better
than bad quantitative measurements. E.g. it is much more important to
find out if there are certain trends in the defects you introduce
(e.g. do you often make mistakes in call parameters, are there defects
in logic constructs, do defects spring from failing to track
specifications, ...), and react to those, than just counting them.
> Of course I have this book. Could you explaind what the Boehm book is
> about.
The book Software Engineering Economics by Boehm (reference see my
previous posting), is one of the first books with a broad treatment of
software metrics, and a data-based estimating process (COCOMO).
Reading it will give you an insight into one approach to software
metrics based estimation processes.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87hf2u39i1.fsf@frown.here>
"Pierre R. Mai" <····@acm.org> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > > Only the programmer-related attributes, which taken all together can
> > > vary from 0.38 to 3.03, do exceed the product complexity related
> > > factors.
> >
> > How have thos programmer-related attributes been measured.
>
> They have not been measured, they were, like all factors in the
> COCOMO, "invented" as part of the estimating framework. They are
> backed by the analysis of projects that went into the COCOMO. Like
> all estimating frameworks, this is just another try to find a simple
> function that can be fitted to the existing metrics.
Thanks for clearing that.
> The exercises are just meant to introduce you to the
> mechanics of metric gathering, and process-based development, and get
> you used to collecting all this stuff in the first place. I don't
> think anyone seriously believes the metrics gathered as part of this
> do constitute any really valid measurements.
Ok, I do not have bothered about the seriousness. But anyway it's
interesting to gather the data and look at them later.
>
> Nowadays I work in a fairly different field, namely that of logistics
> and manufacturing simulations. There you don't write 4 applications a
> year, all similar. You write one framework for >10 years, and at
> least 50% of the code is fairly non-trivial. You write maybe 4
> "applications" a year, but each of those is fairly different, because
> the common parts have already been successfully factored out to the
> framework. KLOC-based productivity measurements give highly-varying
> KLOC/MM numbers.
And how do you estimate the time needed to implement one of those
applications?
>
> > > Since any good process will guide you to reflect on what you
> > > do, it will always improve your work in one way or another.
> > That is probably what all this things are about.
>
> In a way yes, that's what good processes are about. But let me
> suggest that you make other observations on your code and your work,
> and note them down in a notebook while working. Analyse them later.
> Find out in what areas your weaknesses lie, and try to improve those.
> Observe, analyse, again. Good qualitative measurements are better
> than bad quantitative measurements.
I have done in the past and will do in the future. The only thing I
left out is writing it down. So anyway I learned that writing it down
is probably the "best" entry point ;)
>E.g. it is much more important to
> find out if there are certain trends in the defects you introduce
> (e.g. do you often make mistakes in call parameters, are there defects
> in logic constructs, do defects spring from failing to track
> specifications, ...), and react to those, than just counting them.
Good suggestion.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > Nowadays I work in a fairly different field, namely that of logistics
> > and manufacturing simulations. There you don't write 4 applications a
> > year, all similar. You write one framework for >10 years, and at
> > least 50% of the code is fairly non-trivial. You write maybe 4
> > "applications" a year, but each of those is fairly different, because
> > the common parts have already been successfully factored out to the
> > framework. KLOC-based productivity measurements give highly-varying
> > KLOC/MM numbers.
>
> And how do you estimate the time needed to implement one of those
> applications?
By proxy-based estimation: You analyse the problem domain until you
can break the application down into the required parts, and then you
compare those parts with functional units you implemented before, and
based on its closest proxies, your current understanding of the
problem, and some good rules-of-thumb knowledge you make initial
estimates. The more you progress towards a fuller understanding of
the problem, the more you can refine those estimates.
Of course there are always problems that are so dissimilar to anything
you did before that you can't give a reasonable initial estimate. In
that case you might have to invest considerable time just to be able
to offer a good estimate, upon which a go/no-go decision can then be
based. Of course it might be that this approach carries too high a
risk or too high costs, so that the feature in question (or the entire
project) will have to be axed.
Note that similar processes have been used to do KLOC-based
estimation. We don't do this based on KLOCs and KLOCs/MM, for two
chief reasons:
The problem with KLOC/MM in this process is that it relies on the
false statistical assumption that there is one KLOC-productivity
figure for all code for any given team, whereas in reality there are
nearly infinitely many, and the average through them all doesn't give
any meaningful figure. And anyway KLOC/MM doesn't yield any
additional insight, since it just moves the estimation process back
one level: Now you don't have to estimate time, you have to estimate
KLOCs, which is IMHO no easier.
> I have done in the past and will do in the future. The only thing I
> left out is writing it down. So anyway I learned that writing it down
> is probably the "best" entry point ;)
Indeed, since memory is such a fickle thing, magnifying this,
obscuring that... You might be surprised how different things look in
hind-sight, how patterns emerge that were not apparent at the time,
and which would have been overlooked if relying solely on memory.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87ofwxpia5.fsf@frown.here>
"Pierre R. Mai" <····@acm.org> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > > Nowadays I work in a fairly different field, namely that of logistics
> > > and manufacturing simulations. There you don't write 4 applications a
> > > year, all similar. You write one framework for >10 years, and at
> > > least 50% of the code is fairly non-trivial. You write maybe 4
> > > "applications" a year, but each of those is fairly different, because
> > > the common parts have already been successfully factored out to the
> > > framework. KLOC-based productivity measurements give highly-varying
> > > KLOC/MM numbers.
> >
> > And how do you estimate the time needed to implement one of those
> > applications?
>
> By proxy-based estimation: You analyse the problem domain until you
> can break the application down into the required parts, and then you
> compare those parts with functional units you implemented before, and
> based on its closest proxies, your current understanding of the
> problem, and some good rules-of-thumb knowledge you make initial
> estimates. The more you progress towards a fuller understanding of
> the problem, the more you can refine those estimates.
A simular approach is suggested in Watts Humphreys book. He calls it
PROBE size estimating method. PROBE stands for
Proxy-based-Estimating. He suggest using Objects as Proxy, but in
Objects he counts lines. And we are back again, part of the problem is
a decent "LOC" counter.
>
> Of course there are always problems that are so dissimilar to anything
> you did before that you can't give a reasonable initial estimate. In
> that case you might have to invest considerable time just to be able
> to offer a good estimate, upon which a go/no-go decision can then be
> based. Of course it might be that this approach carries too high a
> risk or too high costs, so that the feature in question (or the entire
> project) will have to be axed.
Watts states the same on page 139. I cite
"Large Systems. For systems larger Than 50000 LOC, it could be a major
job to reduce the conceptual design to the level of program
objects."...
And later he states too, how many time one probably will put into such
estimates beforehand.
>
> The problem with KLOC/MM in this process is that it relies on the
> false statistical assumption that there is one KLOC-productivity
> figure for all code for any given team, whereas in reality there are
> nearly infinitely many, and the average through them all doesn't give
> any meaningful figure.
I can agree with this. Anyway we were not talking about KLOC/MM or the
like, just a way to estimate the "size" of a Program.
>And anyway KLOC/MM doesn't yield any
> additional insight, since it just moves the estimation process back
> one level: Now you don't have to estimate time, you have to estimate
> KLOCs, which is IMHO no easier.
Watts has another opinion. He breaks down the estimate on LOC in an
object and uses this for estimating time intervals. I do not know if I
agree with you or him here.
>
> > I have done in the past and will do in the future. The only thing I
> > left out is writing it down. So anyway I learned that writing it down
> > is probably the "best" entry point ;)
>
> Indeed, since memory is such a fickle thing, magnifying this,
> obscuring that... You might be surprised how different things look in
> hind-sight, how patterns emerge that were not apparent at the time,
> and which would have been overlooked if relying solely on memory.
I can't agree more.
Thanks for taking the time to discuss that. But I'm afraid we're off
topic in comp.lang.lisp. Probably comp.software-eng would be a better
place for this discussion.
Regards
Friedrich
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <87ae8ohx4k.fsf@frown.here>
"Christopher J. Vogt" <····@computer.org> writes:
> >
> > What seems to make sense to count e.g comments?
>
> I think if you read literature on LOC, it is defined to not include
lines of all comments or blank lines. I see no reason why this would
be different in Lisp.
You're rigth. But as right was the poster Duane, that ease of
maintenance matters. For that comments are quite helpful. And good
commenting takes time...
>
> Typical use for LOC include defect measurement i.e. in units of defects/kloc, and estimating software development projects. So as long as you are consistent in
> your methodology, it doesn't matter if you expand macros before counting LOC or not because the absolute value of LOC isn't important, it is only used on a
> relative basis.
>
> For example, if lisp projects I have managed with my team of 5 developers in the past have produced an average of 5 KLOC/month of designed, debugged, delivered
> code, and I have a new task I estimate to be 100 KLOC, all things
>being equal, I can estimate about 20 months of work.
That is what Watts Humphrey stresses in the mentions book about the PSP.
>
> If our last delivered product had 1 defect per KLOC and our customers were not complaining about its instability, then when our new product gets to the point
> where we have only 1 defect per KLOC, then we can ship.
>
> In neither of these examples does it really matter *how* I counted
>LOCs, as long as I do it the same way every time.
I fully agree. And because of that Watts asked each one to write down
the standard you will obey and a repeatable way to gather that
information.
Regards
Friedrich
From: Tim Bradshaw
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <ey3n1cncwvv.fsf@cley.com>
* Christopher J Vogt wrote:
> For example, if lisp projects I have managed with my team of 5
> developers in the past have produced an average of 5 KLOC/month of
> designed, debugged, delivered code, and I have a new task I estimate
> to be 100 KLOC, all things being equal, I can estimate about 20
> months of work.
Assuming things scale linearly, which of course they don't.
> If our last delivered product had 1 defect per KLOC and our
> customers were not complaining about its instability, then when our
> new product gets to the point where we have only 1 defect per KLOC,
> then we can ship.
Assumuing all defects are the same, which of course they aren't.
The problem I have with these naive measures is that there's some kind
of tacit assumption that they're within some constant factor of
what you're trying to measure. But I don't think they are, if what
you are trying to measure is something that corresponds to effort or
complexity or something like that.
--tim
Tim Bradshaw <···@cley.com> writes:
> The problem I have with these naive measures is that there's some kind
> of tacit assumption that they're within some constant factor of
> what you're trying to measure. But I don't think they are, if what
> you are trying to measure is something that corresponds to effort or
> complexity or something like that.
That tacit assumption is not always there. I think that when these
informal metrics are applied, there is an implied understanding of the
scope to which they can be relied upon. Some may have a better
understanding that others.
I would not think that too many people worth considering would apply a
constant factor across klocs when doing this informal calculation, or
think that it covers CGI scripts and expert systems alike.
Also, when these informal metrics are used, it's often to produce only
the most rudimentary of estimates, a ballpark figure, suitable for a
quick write-up or pre-qualiication of RFPs. It's like the way an
experienced dry-waller can look at a house as he drives by it on the
way to his work site, and estimate within a few thousand what the cost
will be. The same person might go stone silent if you asked him for a
quick estimate on a 200 room hotel, recognizing the limit of his
informal heuristic.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
From: Tim Bradshaw
Subject: Re: loc measurement for Common Lisp?
Date:
Message-ID: <ey3y9w7b608.fsf@cley.com>
* Craig Brozefsky wrote:
> Also, when these informal metrics are used, it's often to produce only
> the most rudimentary of estimates, a ballpark figure, suitable for a
> quick write-up or pre-qualiication of RFPs. It's like the way an
> experienced dry-waller can look at a house as he drives by it on the
> way to his work site, and estimate within a few thousand what the cost
> will be. The same person might go stone silent if you asked him for a
> quick estimate on a 200 room hotel, recognizing the limit of his
> informal heuristic.
I'd like to know how many large software projects stay *anywhere near*
the initial ballpark estimates, and what metrics were used to create
those estimates for those that met them and those that didn't, before
giving a metric any credence at all.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Craig Brozefsky wrote:
>
> > Also, when these informal metrics are used, it's often to produce only
> > the most rudimentary of estimates, a ballpark figure, suitable for a
> > quick write-up or pre-qualiication of RFPs. It's like the way an
> > experienced dry-waller can look at a house as he drives by it on the
> > way to his work site, and estimate within a few thousand what the cost
> > will be. The same person might go stone silent if you asked him for a
> > quick estimate on a 200 room hotel, recognizing the limit of his
> > informal heuristic.
>
> I'd like to know how many large software projects stay *anywhere near*
> the initial ballpark estimates, and what metrics were used to create
> those estimates for those that met them and those that didn't, before
> giving a metric any credence at all.
Well, I can't speak to your "large software project" but I can say
that in my experience they have been sufficiently close to allow my
work as a consultant to be profitable. This includes projects as
small as 5 hours of work, up to a dozen or more man months. In the
larger cases the initial estimates hae been off by as much as 20% up
or down. This is why we don't base our bids on such things, but use
them just for pre-qualification and quick estimates in the
pre-analysis phase.
Some of us don't have the luxury of telling our clients and coworkers
that since we don't have sufficient feedback on our software metrics
we cannot provide them with a work schdule or estimate just yet, and
they should get back to me when the numbers are in.
I don't have any personal interest in software metrics beyond their
use in business, so I'm not concerned with developing beyond my
current needs. Obviously someone at NASA can't get away with what I
can.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
Craig Brozefsky <·····@red-bean.com> writes:
On a second reading, I thought my response may have had an unwanted
tone too it. Please don't take it as some "real world" or "business
savvy programmer" cop-out response meant to belittle the people who
are doing research into software metrics and furthering the science of
programming. I was attempting to point out that the informal
standards that we all use during our days of coding have real
usefulness, provided their limits are understood.
> Well, I can't speak to your "large software project" but I can say
> that in my experience they have been sufficiently close to allow my
> work as a consultant to be profitable. This includes projects as
> small as 5 hours of work, up to a dozen or more man months. In the
> larger cases the initial estimates hae been off by as much as 20% up
> or down. This is why we don't base our bids on such things, but use
> them just for pre-qualification and quick estimates in the
> pre-analysis phase.
>
> Some of us don't have the luxury of telling our clients and coworkers
> that since we don't have sufficient feedback on our software metrics
> we cannot provide them with a work schdule or estimate just yet, and
> they should get back to me when the numbers are in.
>
> I don't have any personal interest in software metrics beyond their
> use in business, so I'm not concerned with developing beyond my
> current needs. Obviously someone at NASA can't get away with what I
> can.
>
>
> --
> Craig Brozefsky <·····@red-bean.com>
> In the rich man's house there is nowhere to spit but in his face
> -- Diogenes
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes