Measuring SLOC in Tcl
Owen Funkhouser
For script based languages, I've see two types of measures for SLOC: one is
a word count (excluding comments) and the other is non-blank, non-comment
lines.
I'm posting this message today to see how you, Tcl developers, calculate
SLOC in your Tcl code. And in getting feedback from each of you, try to
determine which method is the most popular and does the best job at
measuring the end product.
Thanks for your time ...
Kevin Kenny
non-blank, non-comment lines, defining a "comment line" as any line beginning
with whitespace and # (not entirely accurate, but close enough on most Tcl
files). Halstead's V and E are easier to fit into Tcl, with program length
being word count and program vocabulary being number of distinct words.
http://www.sei.cmu.edu/activities/str/descriptions/halstead_body.html
With that metric, by the way, I assume that Tcl is Capers Jones language
level 6, and "back of the envelope" budget 55 lines of code per function point
(Mark II) deployed.
http://www.gifpa.co.uk/library/Resources/MkIIr131.pdf
(I'm not at liberty to discuss FP per staff month.)
Kevin
--
73 de ke9tv/2, Kevin KENNY GE Corporate R&D, Niskayuna, New York, USA
Arjen Markus
>
> I don't like SLOC as a metric, but if Old Pointy Hair insists on it, I use
> non-blank, non-comment lines, defining a "comment line" as any line beginning
> with whitespace and # (not entirely accurate, but close enough on most Tcl
> files). Halstead's V and E are easier to fit into Tcl, with program length
> being word count and program vocabulary being number of distinct words.
>
If you are looking for a general discussion of software metrics,
then N. Fenton's "Software metrics: a rigourous approach" (Chapman and
Hall, 1991) is very good book.
One of the advices (if I am not mistaken in this book) is to simply
define SLOC (and other metrics) in a straightforward way that can
be measured automatically without trying to be too clever about
what it actually means:
sum = 0 ;
for ( int i=0; i<10; i ++ )
{
sum = sum + i*i ;
}
Well, I count 4 semicolons in this fragment and 5 lines of code
(if I simply use the line count and leave out "obvious" comment
lines).
Should I write this as:
sum = 0 ;
for ( int i=0; i<10; i ++ ) sum = sum + i*i ;
it is only 2 lines of course. Same number of semicolons,
Now:
for ( int i=0, sum=0; i<10; i++, sum=sum+i*i ) {}
One line, 2 semicolons.
What does this say about the complexity? Do not try to correlate
the three fragments! Simply accept that such metrics are measuring
something, but not just complexity.
So: use a simple, easy to understand definition. It measures what
it measures and it may or may not be useful.
Regards,
Arjen
Cameron Laird
Arjen Markus <Arjen....@wldelft.nl> wrote:
.
.
.
>the three fragments! Simply accept that such metrics are measuring
>something, but not just complexity.
>
>So: use a simple, easy to understand definition. It measures what
>it measures and it may or may not be useful.
.
.
Seconded, with feeling.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Stefan Finzel
Donal K. Fellows
> I'm posting this message today to see how you, Tcl developers, calculate
> SLOC in your Tcl code. And in getting feedback from each of you, try to
> determine which method is the most popular and does the best job at
> measuring the end product.
Well, I prefer "major deliverables achieved per month" but then as a Tcler, I
feel this is far fairer to me than it is to programmers stuck using many other
languages... :^)
Donal (tongue not entirely in cheek)
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- Short attention span since- ooh! Shiny thing on the floor!
-- Chad R. Orzel <orz...@earthlink.net>
Dan Smart
news:3CD83E35...@hi-nospam-waay.net:
I don't measure SLOC at all, ever. Why are you interested in code metrics?
What are you trying to measure? What do you believe to be the value of that
measurement? Why do you believe it to be valuable?
I offer the following two "C" functions:
int
foo(int value)
{
int i = 1;
while (i != 0)
{
int ni = value & i;
value ^= i;
i = ni << 1;
}
return value;
}
int
bar(int value)
{
return ++value;
}
Assuming these were written by two different programmers, who was the more
productive?
Assuming that both functions were delivered in the same amount of time, who
was the more productive?
If foo() were delivered before bar(), who was the more productive?
If bar() were delivered in 1/5th the time taken to deliver foo(), who was
the more productive?
What is the difference in complexity between foo and bar?
How do you measure that difference?
How does it relate to the difference in complexity of the underlying
problems?
Ok, so that last one is a trick question. Metrics on problem complexity are
one of the really interesting unsolved questions in mathematics, and by
derivation computer science. There is a significant support for the belief
that in the general case, the best you can possibly do is give a lower
bound, and no one is yet entirely sure of how you even calculate that. If
you can't measure the complexity of the problem, how is measuring anything
about the solution informative?
If it's not obvious yet, both the above functions return (value + 1). bar()
is obviously a far better solution than foo(), and hence I consider the
programmer of bar() to be far more useful than the programmer of foo(). So
what exactly does SLOC measure?
In my penultimate week at work, I replaced 300+ lines of code with 10-20
lines, do I score -280, +20, or what? Does it matter that I wrote the
original 300+ lines?
Dan "I bet I can make incrementing a variable way more obscure, and
probably longer if I try" Smart
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
ADDvantaged
Cameron Laird
Dan Smart <cpp...@dansmart.com> wrote:
>Owen Funkhouser <fu...@hi-nospam-waay.net> wrote in
>news:3CD83E35...@hi-nospam-waay.net:
>
>> In languages such as C++, I've seen SLOC measured by couting
>> semi-colons. For script based languages, I've see two types of
>> measures for SLOC: one is a word count (excluding comments) and the
>> other is non-blank, non-comment lines.
>>
>> I'm posting this message today to see how you, Tcl developers,
>> calculate SLOC in your Tcl code. And in getting feedback from each of
>> you, try to determine which method is the most popular and does the
>> best job at measuring the end product.
>>
>> Thanks for your time ...
>>
>
>I don't measure SLOC at all, ever. Why are you interested in code metrics?
>What are you trying to measure? What do you believe to be the value of that
>measurement? Why do you believe it to be valuable?
.
.
>Assuming these were written by two different programmers, who was the more
>productive?
.
.
>Ok, so that last one is a trick question. Metrics on problem complexity are
>one of the really interesting unsolved questions in mathematics, and by
>derivation computer science. There is a significant support for the belief
>that in the general case, the best you can possibly do is give a lower
>bound, and no one is yet entirely sure of how you even calculate that. If
>you can't measure the complexity of the problem, how is measuring anything
>about the solution informative?
.
.
Dan, you sound a bit touchy on this subject.
I'm sympathetic. OF COURSE software metrics have been
enlisted in the service of utterly hare-brained manage-
ment schemes. Of course one can create all sort of
demonstrations that conventional measures don't have
convenient properties of transitivity, symmetry, and so
on. Yes, evaluation of software developers is probably
a more complex task than that of, say, galley slaves,
or garment piece-workers.
Maybe Mr. Funkhouser didn't know that. He surely does
now.
Maybe he did know that, and failed to make clear he's
measuring software work products for intellectually
legitimate reasons. He might, for example, find it
informative to measure program complexity crudely in
order to estimate likely future maintenance requirements--
quite apart from any ability to "measure the complexity
of the problem".
Anyway, regarding the latter, you surely know the function-
point people deny your bleak conclusion.
One other substantive point on this topic needs to be
said: the research that's been done concludes that such
obviously flawed metrics as SLOC are roughly as useful as
measures that appear to be far more sophisticated. Again,
I don't know whether Mr. Funkhouser knows this.
I applaud the urgency of the questions with which you be-
gan your follow-up: "Why ...? What ...? ..."
Kevin Kenny
> I don't measure SLOC at all, ever. Why are you interested in code metrics?
> What are you trying to measure? What do you believe to be the value of that
> measurement? Why do you believe it to be valuable?
>
> I offer the following two "C" functions:
[...]
> Assuming these were written by two different programmers, who was the more
> productive?
[...]
> What is the difference in complexity between foo and bar?
It sounds from the tone of your posting that you've at some point had
a pointy-haired boss attempt to rate and rank implementors according
to software metrics. Such bosses get exactly what they deserve when
the programmers see through them and start manipulating the metrics.
I can tell horror stories about pointy-haired bosses mismanaging metrics,
too.
You need some sort of metrics to estimate jobs (cost, schedule, staffing),
and over the life of the project to defend against requirements creep
(Yes, I can do that, and according to my estimates, it will cost $X,
delay the schedule by Y months, and require Z staff...) You need some
way to budget for system test, maintenance, configuration control,
all the supporting functions.
It's not clear to me that metrics actually are more accurate than
the guesswork of a skilled estimator. Metrics calibrated with
organizational history, though, are more credible. Which is a big
point when you're negotiating with higher management and with the
customer. Moreover, calibrating them gives you a systematic way to
transfer your knowledge about organizational performance to the next
estimator.
Does SLOC have a place in this? Possibly. It's a bad metric for many
things, but it's probably as good as any for things like "the regression
test suite covers X lines of code out of Y lines deployed", or
"module Foobar has had X reported defects per month per KSLOC, it's
a candidate for refactoring", or even "our last project implemented
P function points in Q lines of Tcl code, let's estimate log(Q/P) as
Tcl's language level."
Metrics are nothing without calibration.
Darren New
> Assuming that both functions were delivered in the same amount of time, who
> was the more productive?
I believe it was Djikstra who said that SLOC doesn't measure results, it
measures cost. You *spend* SLOC.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
The 90/10 rule of toothpaste: the last 10% of
the tube lasts as long as the first 90%.
Cameron Laird
>Dan Smart wrote:
>> Assuming that both functions were delivered in the same amount of time, who
>> was the more productive?
>
>I believe it was Djikstra who said that SLOC doesn't measure results, it
>measures cost. You *spend* SLOC.
.
.
A liability, not an asset.
For cheap thrills, walk into ANY managerial situation, and try
reversing "liability" and "asset". You'll sound like a guru.
Sometimes it's even meaningful.
Anyone know what Djikstra's up to these days? Someone ought to do
better than <URL: http://max.cs.kzoo.edu/~jatkins/dijkstra.htm >.
lvi...@yahoo.com
According to Cameron Laird <cla...@starbase.neosoft.com>:
:OF COURSE software metrics have been
:enlisted in the service of utterly hare-brained manage-
:ment schemes.
And when one's management demands a SLOC , one can certainly try to
provide some level of argument against the numbers, but at the end of things,
one is left either agreeing, reluctantly or otherwise, to produce such
numbers, or left leaving the employer.
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
bo...@aol.com
If you pay programmers based on sloc productivity and you ask for the
functionallity of bar(), the implementation you will get is foo() or
worse. Is that really what you want?
bob
PS: Very nice post Dan.
Kevin Kenny
> I believe it was Djikstra who said that SLOC doesn't measure results, it
> measures cost. You *spend* SLOC.
Y'know, in my earlier post where I was using SLOC as a metric, it was
always for estimating cost, and never value. Dijkstra is onto something,
as he is so often.
Used appropriately, it can be a useful metric, although there are ones
that are marginally better. Measuring programmer productivity is an
INAPPROPRIATE use.
Dan Smart
news:1BEFE2347A8A03A8.C02585A5...@lp.airnews.net:
I get really wound up by people who insist on measuring things, without
understanding what they are measuring, what that measurement actually
means, or even why they want to measure it:
>>> of you, try to determine which method is the most popular and does
>>> the best job at measuring the end product.
Measuring what about the end product? How big it is? How complex it is? The
answers to these questions may have significant impact on the definition of
"Significant", and will have significant impact on the definition of
"best".
Why is popularity relevant?
I am appalled by how common it is for people to attach meaning to the
magnitude of a "number" when the simple act of only being interested in
it's magnitude destroys any meaning it once had. I have seen too many
database purchse decisions influenced by TPC numbers (which are rigorously
defined), without any understanding of the target system's transactional
usage model.
>
> I'm sympathetic. OF COURSE software metrics have been
> enlisted in the service of utterly hare-brained manage-
> ment schemes. Of course one can create all sort of
> demonstrations that conventional measures don't have
> convenient properties of transitivity, symmetry, and so
> on. Yes, evaluation of software developers is probably
> a more complex task than that of, say, galley slaves,
> or garment piece-workers.
>
I overdid that rant (at least a bit). I still consider it likely that the
OP was primarily interested in code-metrics as a measure of productivity.
> Maybe Mr. Funkhouser didn't know that. He surely does
> now.
To my mind at least, there is no evidence yet to either confirm or deny
that final statement :-)
>
> Maybe he did know that, and failed to make clear he's
> measuring software work products for intellectually
> legitimate reasons. He might, for example, find it
> informative to measure program complexity crudely in
> order to estimate likely future maintenance requirements--
> quite apart from any ability to "measure the complexity
> of the problem".
It is worth pointing out that there is increasing evidence that source code
metrics are not significantly more useful for estimating future maintenance
requirements than they are as a way of measuring productivity. The best way
for estimating maintenance requirements is as follows:
1) Divide your code universe into single-threaded and multi-threaded
programs.
2) For each group gather statistics on approximate number of bugs in a
given size of program, and the length of time they take to fix.
3) With enough data points, you can now estimate the number of bugs (n)
expected to be found per time unit (t) per unit of code size (s), and a
lower and upper bound (l and u) on time to fix.
Note the careful way I swept "size" under the carpet? What is a good
measure of size?
1) For a normal team (with some turnover of members), the signal to noise
ratio of the executable code remains fairly constant as are the number of
bugs per unit of signal.
2) For a maturing team (low to zero turnover) the signal to noise ratio
increases over time, and the number of bugs per unit of signal may
decrease, but this drops out of your statistics as a constant.
3) For a new team, you will not have sufficient data points to make any
reasonable estimates...
Thus "executable size" is as good a measure of "program size" as any for
estimates of maintenance cost.
>
> Anyway, regarding the latter, you surely know the function-
> point people deny your bleak conclusion.
I lied by implication in my article, I implied that I have no interest in
code-metrics, and of course I do. Providing meaningful metrics on system
complexity, is a fascinating field of research (although I'm at least a
couple of years out of date), it is not research that had (at least a
couple of years ago) demonstrated real world utility. In general the
statistical methods used to calculate useful data from such metrics are
relatively impervious to errors in measurement (as long as such errors are
either constant, or have a multipicative constant related to time), and
hence even significant refinenments in measurement have little effect on
the accuracy of the results.
With respect to the measurement of complexity, the function-point approach
has achieved some real wins at least in their analysis of static
complexity. It is however an unjustified leap of faith to argue that for
non-trivial problems; once you have a program that implements a solution to
a problem, then measuring the complexity of that implementation gives you
an upper bound on the complexity of the problem. To prove that this is a
genuine upper bound, it is necessary to prove that the program actually
implements a solution to the original problem. It is easy to prove that
this is not guaranteed to be possible, and even were this not the case,
such program proving is for non-trivial problems, decidely non-trivial.
Without such proof, you cannot even prove that what you have is an
approximation to such an upper bound, although you can demonstrate a degree
of statistical certainty.
The analysis of the dynamic complexity of multi-threaded systems had made
far less progress last time I looked. Turing completeness proves that any
multi-threaded program can be re-written to be single threaded, and
effectively is (although non-deterministically) when run on a single cpu
machine. I'm pretty sure that in the general case, automating a
deterministic re-write with identical dynamic behaviour is equivalent to
solving the halting problem, and hence impossible, but would be delighted
to be corrected.
Finally of course none of the above addresses the complexity (and hence
probability of faults) added by external constraints on resources
(including for instance finite memory, and more interestingly required
upper bounds on response times). Which is not to imply that significant
research has not been done in these areas.
>
> One other substantive point on this topic needs to be
> said: the research that's been done concludes that such
> obviously flawed metrics as SLOC are roughly as useful as
> measures that appear to be far more sophisticated. Again,
> I don't know whether Mr. Funkhouser knows this.
And as shown above likely no more useful than "ls -l" :-)
>
> I applaud the urgency of the questions with which you be-
> gan your follow-up: "Why ...? What ...? ..."
It is interesting (to me at least) that the functions I offered:
>> int
>> foo(int value)
>> {
>> int i = 1;
>> while (i != 0)
>> {
>> int ni = value & i;
>> value ^= i;
>> i = ni << 1;
>> }
>> return value;
>> }
>>
>> int
>> bar(int value)
>> {
>> return ++value;
>> }
demonstrate one of the other traps of code metrics: while foo() is
obviously more complex than bar(), a slightly re-written form of foo()
(where certainty of loop termination is made explicit) is easier to apply
some forms of "program correctness" analysis to, and that such analysis
will frequently effective substitute bar() with foo2().
disk-lamer:
Note that this was really a follow up to several follow-ups. I apologise in
advance if I "lectured", and for errors of fact. Usage of rhetorical
questions was not meant to imply that any of the people who responded to my
article were un-aware either of the question, or its implications...
Dan "Who is concerned to have found his interest in such matters re-
awakened given his resource constraints" Smart
Kevin Kenny
> Thus "executable size" is as good a measure of "program size" as any for
> estimates of maintenance cost.
Indeed. Observe, though, that if language level is held constant, executable
size should scale as a linear function of SLOC, and by implication, "SLOC
is as good a measure as any of 'program size.'" Moreover, "executable size"
has to be calibrated to the target platform, where SLOC is target-independent.
Aren't we then looking at two sides of the same inadequate measure?
> With respect to the measurement of complexity, the function-point approach
> has achieved some real wins at least in their analysis of static
> complexity.
Indeed. Which is why I prefer function points as a metric when estimating
implementation cost -- at least with the usual, "bread and butter" application
development scenarios. Embedded systems, multi-threading, systems
programming in general are much less well calibrated, owing to the dynamic
complexity that you mention. This complexity is part of what makes the
widespread deployment of Java such a tragedy; having to resort to threads
in order to run a GUI makes things insanely difficult for the typical
programmer.
I applaud the work of researchers who are trying to bring us better science
for all this. In the meantime, I need some way to estimate jobs that's
better than pulling numbers out of a hat. Function points and SLOC
aren't exactly the sharpest tools, but a dull knife still beats a flint
pebble.
Cameron Laird
Dan Smart <cpp...@dansmart.com> wrote:
.
.
.
>1) Divide your code universe into single-threaded and multi-threaded
>programs.
.
.
You've got me curious.
Nearby, Kevin mentioned the cruelty of Java's insistence
that GUI programmers multi-thread. I happen to agree with
his observation, by the way; I frequently advise newcomers
that they're likely to find, for example, Tk GUI programming
particularly comprehensible.
Elevation of threading to the single most salient dimension
of coding surprises me, though. Are you saying, Dan, that
that one boolean variable explains more of solution complex-
ity than any other? Is that only for (end-user) "application"
programming? Is there solid research that threading is a
more difficult concurrency model than any of the alternatives?
Dan Smart
> In article <Xns920B92...@167.206.112.134>,
> Dan Smart <cpp...@dansmart.com> wrote:
> .
> .
> .
>>1) Divide your code universe into single-threaded and multi-threaded
>>programs.
> .
> .
> .
> You've got me curious.
>
> Nearby, Kevin mentioned the cruelty of Java's insistence
> that GUI programmers multi-thread. I happen to agree with
> his observation, by the way; I frequently advise newcomers
> that they're likely to find, for example, Tk GUI programming
> particularly comprehensible.
>
> Elevation of threading to the single most salient dimension
> of coding surprises me, though. Are you saying, Dan, that
> that one boolean variable explains more of solution complex-
> ity than any other? Is that only for (end-user) "application"
> programming? Is there solid research that threading is a
> more difficult concurrency model than any of the alternatives?
As with all sweeping generalisations, its truth value varies. There is for
a start a continuum of threading models, not all of which are "classically
multi-threaded", although increasingly "multi-threaded behaviour" is being
modeled with multiple threads.
The fundamental issues are: concurrency, synchronisation and re-entrancy.
True multi-threaded solutions typically (although not always) exhibit all
of these issues to a great degree, other solutions are usually less
affected to some degree.
Pseudo-multi-threading: multiple processes with shared memory.
==============================================================
Affected by concurrency and the need for synchronization, with the
attendant risks of data-corruption and deadlock. Typically re-entrancy is
not a significant issue (unless some clever sob has figured out how to make
shared memory pages executable - but it was a long time ago, and I regret
it).
Threads as "event converters".
==============================
I frequently use threads to overcome Unices inability to wait on
collections of anything other than file descriptors. These threads block on
data/event availability and forward the data/event as a message on a queue,
or block on "writeability", and write dequeued data when such a state
occurs. These solutions are minimally affected by any of the stated issues,
and are in fact typically simpler than the single threaded solution.
Event driven architectures.
===========================
Not "classically multi-threaded" at all, and in their classical form,
pretty much immune to all the fundamental issues. But, as is being
wonderfully demonstrated in 'Can "fileevent procs" be Re-entered', the
presence of recursive event loops introduces something not dissimilar to
co-operative multi-threading, and hence a variety of subtle, timing
critical bugs.
To an extent, multi-threaded programs are more complex than single threaded
programs becuase the problems they are addressing are more complex, but
they are also more complex because the tool itself is complex. There is an
element of recursivity here, to solve complex problems you can either use
powerful tools (which are by there nature more complex than simpler tools),
or you can keep the complexity in application space. Tcl programs are in
general "simple" because Tcl itself is complex, but as is repeatedly
discovered you can't completely hide that complexity. One of Java's
failings is that in the quest for simplicity in the language, they have
pushed complexity into application space. C++'s major failing is that
backward compatability with C has made it more complex than a language of
its power needs to be. Experience leads me to believe that for very large
systems, a good C++ solution is "simpler" than a good Java solution, and
both require "expert" programmers with equivalent levels of experience.
Note also, mutli-threaded programs may be more complex than single threaded
programs because multi-threading was an inappropiate choice of solution,
think Swing. But that is generally true, inappropiate technology choices
lead to overly complex solutions.
Still, my original point was specifically related to estimating maintenance
costs. The subtlety and timing related nature of the problems that
typically affect multi-threaded programs mean that they usually have
different maintenance characteristics to their single threaded brethren.
Not necessarily worse mind you, but certainly different. This is directly
related to dynamic complexity, the code for a multi-threaded solution may
well be significantly simpler than the equivalent single threaded solution,
and hence will harbor fewer bugs. The nature of those bugs is likely such,
that detection and elimination is significantly harder, and hence takes
longer.
It is certainly the case that static analysis of the complexity of a multi-
threaded program is itself significantly more complex than analysing the
complexity of a single-threaded program.
Finally, I can't resist pointing out that I love Swing. Whenever Java
advocates talk about features of their language/environment that make it
superior to every other language on the planet, I can always use Swing as a
counter example. "Garbage collection means no memory leaks", so why does
Swing leak memory, oh because it forgets to remove things from collections
when it's done with them. "Java makes multi-threading easy", which is why
Swing uses it instead of an event driven architecture, and hence why Swing
is so complex. "Java makes multi-threading safe", and Swing is slow
directly due to over granular synchronization. "Java manages resources for
you", no Java manages a resource "memory" for you, which is why when Swing
forgets to deterministically finalize objects, you can run out of "Graphics
Contexts", "Cursors", "Pens" etc. The list goes on...
Dan "That's my dig at Java done for the week" Smart.
Dan Smart
> Dan Smart wrote:
>> Thus "executable size" is as good a measure of "program size" as any
>> for estimates of maintenance cost.
>
> Indeed. Observe, though, that if language level is held constant,
> executable size should scale as a linear function of SLOC, and by
> implication, "SLOC is as good a measure as any of 'program size.'"
> Moreover, "executable size" has to be calibrated to the target
> platform, where SLOC is target-independent. Aren't we then looking at
> two sides of the same inadequate measure?
I'm not sure exactly which part of my brain temporarily gained control
while writing that section, I meant "source", not "executable". As in "For
a normal team, the signal to noise ratio of the source code remains fairly
constant...". Thus my implied argument was why bother measuring "SLOC",
with all the difficulties of defining "Significant", and indeed "line",
when "LOC" (wc -l) or "BOC" (ls -l) will do just as well.
(note that executable size is not a bad measurement, just suffers from the
calibration issues you mention. But if you only develop for a single
platform...)
>
>> With respect to the measurement of complexity, the function-point
>> approach has achieved some real wins at least in their analysis of
>> static complexity.
>
> Indeed. Which is why I prefer function points as a metric when
> estimating implementation cost -- at least with the usual, "bread and
> butter" application development scenarios.
I've always found that "Ask each developer in the team how long they think
it will take, sum those answers, double that and convert to the next
highest unit" to be a really good estimate of implementation cost :-)
Seriously though, function points are (used appropiately of course) a
useful metric.
> Embedded systems,
> multi-threading, systems programming in general are much less well
> calibrated, owing to the dynamic complexity that you mention.
All tools involve a complexity trade off: A tool contains internal
complexity which simplifies the solution of some part of a problem, and an
external complexity which is the price that you pay for that power. In
general, these are related in that for a given degree of power there is an
implicit minimum degree of complexity. For some tools that price is payed
in dynamic complexity, for others in static complexity, but the price will
be paid.
TCL is a very powerful tool for solving a significant class of problems. It
is a mistake to believe that it is "simple", or that it has no external
"complexity cost". "update", "vwait", "uplevel" and "eval" are but a few
testaments to that. I would argue that "fixing" the preceeding, will just
push the complexity somewhere else, which isn't to say that fixing them
would be a mistake.
To paraphrase Bjarne Stroustrup "simple intuitive behaviour is inherently
complex, that complexity is invisible when it works right and devastatingly
surprising in the edge cases."
> This
> complexity is part of what makes the widespread deployment of Java
> such a tragedy; having to resort to threads in order to run a GUI
> makes things insanely difficult for the typical programmer.
>
Java the language values minimizing external complexity, and as such is a
less powerful problem solving tool than it could/should be, hence it drives
complexity into application code. Also by apparently simplifying the
usage of some of the powerful tools it does provide, it encourages their
inappropiate use. Swing demonstrates that the apparent simplicity of multi-
threading in Java is illusory, and that further because it is an
inappropiate tool, application code pays the complexity price and receives
little or nothing in return.
> I applaud the work of researchers who are trying to bring us better
> science for all this. In the meantime, I need some way to estimate
> jobs that's better than pulling numbers out of a hat. Function points
> and SLOC aren't exactly the sharpest tools, but a dull knife still
> beats a flint pebble.
>
Agreed, except I contine you to argue that "Lines of Code" or even "Bytes
of Code" are just as useful as "Significant Lines of Code", and both the
former are easier and less contraversial to calculate.
Dan "Who is just going take his 747 for a quick trip to the shops" Smart
Darren New
> I've always found that "Ask each developer in the team how long they think
> it will take, sum those answers, double that and convert to the next
> highest unit" to be a really good estimate of implementation cost :-)
> Seriously though, function points are (used appropiately of course) a
> useful metric.
Actually, there's a lot of evidence that programmers are really *good*
at estimating how long a task will take. What they're bad at is
estimating how much calendar time it'll take to get a given amount of
programming time. That is, a programmer may say "a week" when she means
"40 hours of programming", and in reality only manage to get 15 hours of
programming time, the rest spent in meetings, on vacation, dealing with
customers, filling out reports, etc.
That is, in experiments where you measure how much time the coders spend
coding, you get very accurate results if you ignore the calendar days. I
could probably dig up references if enough people care.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
Dan Smart
> Dan Smart wrote:
>> I've always found that "Ask each developer in the team how long they
>> think it will take, sum those answers, double that and convert to the
>> next highest unit" to be a really good estimate of implementation
>> cost :-) Seriously though, function points are (used appropiately of
>> course) a useful metric.
>
> Actually, there's a lot of evidence that programmers are really *good*
> at estimating how long a task will take. What they're bad at is
> estimating how much calendar time it'll take to get a given amount of
> programming time. That is, a programmer may say "a week" when she
> means "40 hours of programming", and in reality only manage to get 15
> hours of programming time, the rest spent in meetings, on vacation,
> dealing with customers, filling out reports, etc.
>
Indeed, while my tongue was firmly in my cheek, you are entirely correct.
Further, it is an annoying fact of work life that a not unreasonable
conversion from "programming" time to "elapsed" time is to double and
convert to the next highest unit. It is a fact of life that the smallest
unit of interuption is somewhere between 15 minutes and half an hour, thus
a relatively small number of interuptions can convert a half hour task to a
one day task.
> That is, in experiments where you measure how much time the coders
> spend coding, you get very accurate results if you ignore the calendar
> days. I could probably dig up references if enough people care.
>
If you haven't read "Peopleware" and weren't refering to it, you should...
http://www.amazon.com/exec/obidos/ASIN/0932633439/ref=ase_inktomi-bkasin-
20/102-6645937-8631343
Dan.
Darren New
> If you haven't read "Peopleware" and weren't refering to it, you should...
In part. The XP people also promote similar metrics, and there *might*
be something in Mythical Man Month, but it's been too long since I read
that to be sure.
Arjen Markus
>
>
> Anyone know what Djikstra's up to these days? Someone ought to do
> better than <URL: http://max.cs.kzoo.edu/~jatkins/dijkstra.htm >.
Edsger Dijkstra (I took the liberty of correcting the typo :-) has
retired from his professorate (correct English?) one or two years
ago. His (mostly hand-written) collected papers (the stuff he
ultimately became famous for!) are available on-line, but I could
not find the proper URL.
Regards,
Arjen
PS The "ij" is pronounced as one vowel, something akin to "i" in the
English "like", and "ei" in the German "Speise"
Arjen Markus
>
> I am appalled by how common it is for people to attach meaning to the
> magnitude of a "number" when the simple act of only being interested in
> it's magnitude destroys any meaning it once had. I have seen too many
> database purchse decisions influenced by TPC numbers (which are rigorously
> defined), without any understanding of the target system's transactional
> usage model.
A couple of years ago we had a rather lame joke for distinguishing
engineers from academics (both types of education abound here).
Any one who could not answer the following question was NOT
an engineer:
What is the number of concrete? (You know the stoney stuff)
The purpose was not to hear "the" number, any number would do.
This just as an aside.
I think that having simple measures for software products is good
- if you use it for the proper reasons, as emphasized by many
respondants. It should be a tool for the programmer, not for
a job appreciation scheme.
(SLOC is just as good as anything else - I once determined the
correlation between SLOC and the number of decisions, loops, ...,
anything simple I could come up with. Boy, I never saw such straight
lines!)
Regards,
Arjen
Arjen Markus
>
> >
> Agreed, except I contine you to argue that "Lines of Code" or even "Bytes
> of Code" are just as useful as "Significant Lines of Code", and both the
> former are easier and less contraversial to calculate.
>
I read once (in Les Hatton's "Safer C"?) that another metric strongly
correlated to LOC/SLOC and the like is the weight of the paper
on which the listing is printed (of course, to compare this metric
to metrics taken at another site, you need some calibration factor).
Regards,
Arjen
Donal K. Fellows
> int
> foo(int value)
> {
> int i = 1;
> while (i != 0)
> {
> int ni = value & i;
> value ^= i;
> i = ni << 1;
> }
> return value;
> }
ISTR seeing code quite like that, but it was in a directly-mapped HDL (I don't
think the cell-library contained an adder) so that's more to be expected.
Division was more fun... :^)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- If somebody in a suit or a uniform can sit you down and have you believe
every word he says, you've just surrendered your license to be a thinking
human being and traded it in for a zombie suit. -- mh...@prince.carleton.ca
Donal K. Fellows
> The fundamental issues are: concurrency, synchronisation and re-entrancy.
> True multi-threaded solutions typically (although not always) exhibit all
> of these issues to a great degree, other solutions are usually less
> affected to some degree.
Once you've got a handle on those, there's a pack of other things waiting to
jump up and hit you. Analysing systems with multiple (coupled[*]) threads of
execution is deeply hard (I think the easiest way forward is "extremely
defensive" with as little coupling as you can get away with) especially if you
want to put timing constraints on things too.
Donal (deadlock is not the worst thing that can happen...)
[* The uncoupled case is trivial. ]
David Wijnants
>
> PS The "ij" is pronounced as one vowel, something akin to "i" in the
> English "like", and "ei" in the German "Speise"
Yes, I keep getting calls from telephone salesmen - hello, Mr. Widge...
David Wijnants
(Wingnuts, Widepants, Davygoat)
Cameron Laird
Dan Smart <cpp...@dansmart.com> wrote:
.
[bunch of stuff, some
of it incredibly ap-
posite and important]
.
.
>Measuring what about the end product? How big it is? How complex it is? The
>answers to these questions may have significant impact on the definition of
>"Significant", and will have significant impact on the definition of
>"best".
.
.
My tradition is to gloss "SLOC" as "source line(s) of code"
(and I can present plenty of URLs which demonstrate others
do, too). I'm finally catching on that, to you, Dan, it
means "significant lines ...". I feel I now have a little
more insight into how the label could inspire a lot of emo-
tion in you. Perhaps when you hear it, you expect
conversants to be involved in worrying over the difference
between a line-count with and without comments, or fretting
over how to allocate closing '}'-s. Ah-ha! I can assure
you that Kevin and I and I think Arjen are all reasonably
content to "wc -l", as you suggest elsewhere in this thread.
Arjen Markus
>
>
> My tradition is to gloss "SLOC" as "source line(s) of code"
> (and I can present plenty of URLs which demonstrate others
> do, too). I'm finally catching on that, to you, Dan, it
> means "significant lines ...". I feel I now have a little
> more insight into how the label could inspire a lot of emo-
> tion in you. Perhaps when you hear it, you expect
> conversants to be involved in worrying over the difference
> between a line-count with and without comments, or fretting
> over how to allocate closing '}'-s. Ah-ha! I can assure
> you that Kevin and I and I think Arjen are all reasonably
> content to "wc -l", as you suggest elsewhere in this thread.
Yes, I have always understood "Source line(s) of code" (though
the interpretation as "Significant" was revealing!). Hence,
"wc -l" is quite reasonable, or "egrep -v "^#" |wc -l" if
you want an easy way to avoid comments.
Regards,
Arjen
Arjen Markus
I have no such problem, if you forget that Markus/Marcus is a fairly
common first name in German-spoken or English-spoken countries :-)
Regards,
Arjen (yes: the "j" is pronounced like the "y" in "you")
Bob Techentin
>
> Edsger Dijkstra (I took the liberty of correcting the typo :-) has
> retired from his professorate (correct English?) one or two years
> ago. His (mostly hand-written) collected papers (the stuff he
> ultimately became famous for!) are available on-line, but I could
> not find the proper URL.
Perhaps you mean the Dijkstra Archive?
http://www.cs.utexas.edu/users/EWD/
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
Arjen Markus
Yes, that is the one!
Regards,
Arjen