How many lines per day?
Ingo Sander
produce a day. I know that this depends on the language etc, but I´m
most interested in C/C++.
I would appreciate if someone could give a reference to a webpage or
book.
Thank you.
Ingo
Mark Johnson
Ingo Sander wrote in message <38020070...@haninge.kth.se>...
The classic 'bogey' figure has always been 10 lines per programmer-day
of fully documented and tested source code, including design, code,
debug, and unit/module test. Most authorities who cite this figure contend
that it is relatively independent of programming language, which of
course implies that higher level languages are more productive.
I do not really know how accurate this figure is, I've just heard it many
times over. A good place to start looking for a reference is probably
"The Mythical Man-month," by Fred Brooks.
As an aside, some wag computed that the amount of effort required to
push a pencil through 10 lines of code and the associated documentation,
over a year's time, adds up to the same amount of mechanical work
required to move a 14b weight one mile -- or in other words, one
mile-stone. So a team of programmers should be assigned the same
number of major milestones as their headcount, across a full year. :)
[The first two paragraphs above are serious, or as serious as wet-
thumb programming effort estimation ever gets. The latter paragraph
is typed with tongue firmly in cheek.]
Frank Gerlach
construction worker build in one year ?" Building a skyscraper is
somehow more difficult than building a cheap flat. Even the question
"how many square feet will a construction worker build per year ?" is
silly, because it will highly depend onto the degree of luxury etc.
The same is with programming:
-multithreaded code may cause trememdous headaches and can
make even seasoned programmers debugging for days w/o any
substantial progress.
-bad or inexperienced programmers may produce several times
more code than really necessary ( maybe using the
"cut-copy-paste"
methodology). Are they more productive ??
-efficient algorithms are often more complex, meaning that they
require a higher debugging effort; is it better to have a lot
of inefficient functionality or is it better to limit scope
but focus on performance an scalability ? ( I prefer the last,
whilst a lot of managerial types try to maximize the buzzword
count on the data sheet)
-how much testing must be done by development engineers ?
Some organizations think that it is sufficient to be able to
compile the stuff and let the QA dept do the testing.
This will backfire in nearly any case, but maybe this is
not important. If you want high-quality systems, you will
have to allocate as much time on testing (including test
scripts) as on coding.
(for the INDIVIDUAL developer; forget the QA for a moment)
As you can see "lines-of-code/day" is a silly invention of silly
bureaucracies like IBM. FORGET IT.
If a manager needs "lines-of-code" to asess developer performance he/she
is just on the wrong job. Assessing engineering work is in most cases
highly non-objective and it is just bad to try to objectivize it.
If you think your boss does not recognize your contributions, get
another
job..
(No, I do not hate managers in general, just the incompetent ones, just
like
incompetent engineers)
Steve Sheldon
>Can someone give a hint on how many lines of code a programmer can
>produce a day. I know that this depends on the language etc, but I'm
>most interested in C/C++.
>I would appreciate if someone could give a reference to a webpage or
>book.
About 1500 lines per day on average.
How did I calculate this? Some assumptions about the average person and
job:
- types 50 wpm
- there are 8 hours in the work day
- But 3 hours are spent in status meetings
- A line of source has about 10 words. A word in typing is usually defined
as 5 characters, so that would be a 50 character line. If you forget about
whitespace caused by indentation that's probably about right.
This leaves 5 hours * 60 minutes * 5 = 1500 lines
Of course the answer is completely different if the lines actually have to
compile and do something useful. But in terms of sheer typing speed, 1500
is about right.
:-)
--
Steve Sheldon email: she...@yuck.net
BSCS/MCSE url: http://www.sheldon.visi.com
Justin Vallon
> Ingo Sander <in...@haninge.kth.se> writes:
>
> >Can someone give a hint on how many lines of code a programmer can
> >produce a day. I know that this depends on the language etc, but I'm
> >most interested in C/C++.
> >I would appreciate if someone could give a reference to a webpage or
> >book.
>
> About 1500 lines per day on average.
...
> This leaves 5 hours * 60 minutes * 5 = 1500 lines
Maybe if the source is already written, and the programmer is
transcribing the code in from cocktail napkins.
> Of course the answer is completely different if the lines actually have to
> compile and do something useful. But in terms of sheer typing speed, 1500
> is about right.
1500 lines is probably an upper limit on the amount of code that can
be `physically' typed in during a single day.
After typing in 1500 lines, I think this Herculean programmer would
have to take at least a week to test the code. Of course, a Son of
the Gods programmer would probably have no need to debug, or test for
that matter...
> :-)
Ha ha?
--
-Justin
val...@bear.com
Jeffrey C. Dege
>Can someone give a hint on how many lines of code a programmer can
>produce a day. I know that this depends on the language etc, but I´m
>most interested in C/C++.
>I would appreciate if someone could give a reference to a webpage or
>book.
On my most productive single day, the program I was working on had
3000 fewer lines than it did when I started.
--
A complex system that works is invariably found to have evolved from a
simple system that worked ...A complex system designed from scratch never
works and cannot be patched up to make it work. You have to start over,
beginning with a working simple system.
-- Grady Booch
Tom Cloutier
A complex system is one in which the code is real and the documentation
imaginary...
Mike Mohr
>
> About 1500 lines per day on average.
>
> job:
>
> - types 50 wpm
> - there are 8 hours in the work day
> - But 3 hours are spent in status meetings
> - A line of source has about 10 words. A word in typing is usually defined
> as 5 characters, so that would be a 50 character line. If you forget about
> whitespace caused by indentation that's probably about right.
>
>
> compile and do something useful. But in terms of sheer typing speed, 1500
> is about right.
>
reading someplace that you effectively get 47 minutes out of every
hour. Based on your formula, that effectively reduces output to 1175
lines per day. Ah, then we need to factor in newsgroup chat time,
telephone time, break mobility time, etc. (That number keeps getting
smaller.)
================================================================
Mike Mohr, Systems Administrator === Email: Mike...@ait.ac.nz
Information Technology Group === Phone: 64 9 307-9999 x8133
Auckland Institute of Technology === Fax: 64 9 307-9901
PO Box 92006, Auckland, New Zealand =
http://home.ait.ac.nz/staff/mmohr/
================================================================
If we have unlimited ability to think, why do we use computers?
Peter Leeson
<in...@haninge.kth.se> writes:
>Can someone give a hint on how many lines of code a programmer can
>produce a day. I know that this depends on the language etc, but I´m
>most interested in C/C++.
>I would appreciate if someone could give a reference to a webpage or
>book.
>
"Applied Software Measurement" by Capers Jones McGraw-Hill 1996 ISBN
0-07-032826-9
p.213 - depending on the type of application and the complexity of the system,
the average productivity per month varied from 0.90 to 80.0 function points,
with an average at 49.52
p.80 - the number of lines of code in C per function point is minimum 60,
maximum 170 with a mode of 128
p.84 - the number of lines of code in C++ per function point is minimum 40,
maximum 140 with a mode of 55
The answer to your question is that a programmer seems to average between 36
(.90*40) and 13600 (80*140) LOC per month. If you know how many days they work
in a month, you should be able to determine the result.
I recommend, you start measuring, basing the data on your own people, your own
environment, your own levels of complexity and skills. The averages published
are not applicable to you, they can only show that you are above the minimum
and below the maximum with an even chance of being above the average or below
it.
Peter Leeson
www.aimware.com
www.ispi.co.uk
aimware - process made easy
http://www.aimware.com
http://www.ispi.co.uk
Steve Neuendorf
At a client's once, there was an SE who had developed and maintained a
specific engineering calculator application (long long term - key program).
I was there under an initiative to count function points. At an open
session, the SE said he did not like function points. When asked why, his
response was that management required a 10 % productivity improvement per
year. He said that when this was measured with lines of code, it required
about 1 hour per year to add enough lines to get the required "improvement".
With function points, someone had to actually ask him to change or add on to
the program, which really did not happen to this very good and important
program often.
Maybe the answer is how many do you need. Like Jones says (cited elsewhere
in this thread) "what you measure is what you get".
I can just picture you doing this research for a manager "just for his or
her own edification" with within a few days or weeks everyone being made to
show their "X lines" for the day or week.
I guess some things are better off unknown (even if they are knowable).
Good Luck,
Steve
Ingo Sander <in...@haninge.kth.se> wrote in message
news:38020070...@haninge.kth.se...
> Can someone give a hint on how many lines of code a programmer can
> produce a day. I know that this depends on the language etc, but I´m
> most interested in C/C++.
> I would appreciate if someone could give a reference to a webpage or
> book.
>
> Thank you.
>
> Ingo
>
P.S. Norby
>
> Steve Sheldon wrote:
> >
> > About 1500 lines per day on average.
> >
> > How did I calculate this? Some assumptions about the average person and
> > job:
> >
> > - types 50 wpm
> > - there are 8 hours in the work day
> > - But 3 hours are spent in status meetings
> > - A line of source has about 10 words. A word in typing is usually defined
> > as 5 characters, so that would be a 50 character line. If you forget about
> > whitespace caused by indentation that's probably about right.
> >
> > This leaves 5 hours * 60 minutes * 5 = 1500 lines
> >
> > Of course the answer is completely different if the lines actually have to
> > compile and do something useful. But in terms of sheer typing speed, 1500
> > is about right.
> >
<Dilbert>
PHB: I saw the code for your computer program yesterday. It looked
easy. It's just a bunch of typing. And half of the words were spelled
wrong. And don't get me started about your overuse of colons.
Dilbert: They remind me of you, sir.
</Dilbert>
PS Norby
"Software engineers are, in many ways, similar to normal people"
-- Scott Adams
"No excuses. No embarrassment. No apologies...
Ada -- the most trusted and powerful programming language
on earth, or in space." -- S. Tucker Taft
\\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\
( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :)
/// /// /// /// /// /// /// /// ///
(Speaking only for myself)
Wolfgang Keller
after I've seen the discussion here, I have another hint ..
ask the metrics guru Capers Jones. You'll find him
at http://www.spr.com/index.htm
He has written a paper called
THE ECONOMICS OF OBJECT-ORIENTED SOFTWARE
but it's copyrighted so I can't forward it to you.
So just ask him for a copy
This will answer you questions.
To give a short starter: Productivity across different environments
should
best be measured in function points
LOC productivities are dependant on the language you use.
Productivity tends to be higher in higher languages but you need
far less lines of code to do the same thing.
So in LOC you look less productive
But measured in FP you are far more productive.
Hope that helps.
Wolfgang
--
================================================================
EMail: w...@objectarchitects.de
Web: http://www.objectarchitects.de/ObjectArchitects/
Ted Wood
she...@visi.com (Steve Sheldon) wrote:
> About 1500 lines per day on average.
>
You may mock. I've got a guy assigned to my team for the next project
who claims to be able to write 20-40 KLOCs of C a month. Oh, and he
feels that documentation is "a management issue"....
At this rate we should have the project finished before we've started.
Cheers
TW
--
Any views expressed in this message are those of
the individual sender, except where the sender
specifically states them to be the views of Sortex Ltd.
Sent via Deja.com http://www.deja.com/
Before you buy.
Dan
> In article <v6wM3.1071$b84.1...@ptah.visi.com>,
> she...@visi.com (Steve Sheldon) wrote:
>
> > About 1500 lines per day on average.
> >
>
> You may mock. I've got a guy assigned to my team for the next project
> who claims to be able to write 20-40 KLOCs of C a month. Oh, and he
> feels that documentation is "a management issue"....
We have a large amount of legacy source code that needs compacting. If you
could just advise us of his expected landing site ...
d.
Dan
> LOC productivities are dependant on the language you use.
> Productivity tends to be higher in higher languages but you need
> far less lines of code to do the same thing.
> So in LOC you look less productive
> But measured in FP you are far more productive.
This is true, but how does one consistently measure FP? You're
effectively moving the "wet finger" part of the equation to your
complexity measure ...
A point (related to LOC) that seems to have been missed on this thread
(and in the parts of the industry I have been exposed to):
Productivities are generally measured, IMHE, in terms of the LOC of the
product before and after the development phase. Where this is an
addition of functionality to an existing product, this measure is plain
wrong, because lines may have had to be deleted, or changed. The effort
involved in knowing *which* lines to delete, and in changing the others
correctly, is often similar to generating them in the first place.
What we should be doing is measuring the *changed* LOC for the
development. This is easily acheived by using a file difference utility
and counting semicolons for changes ...
d.
Bernard Evenepoel
> who claims to be able to write 20-40 KLOCs of C a month. Oh, and he
> feels that documentation is "a management issue"....
'Real programmers don't document : as it was hard to write, it should be
hard to understand'
Good luck for the maintenance of his code .......
Bernard
Link Hochnadel
>
> Wolfgang Keller wrote:
>
> > LOC productivities are dependant on the language you use.
> > Productivity tends to be higher in higher languages but you need
> > far less lines of code to do the same thing.
> > So in LOC you look less productive
> > But measured in FP you are far more productive.
>
> This is true, but how does one consistently measure FP? You're
> effectively moving the "wet finger" part of the equation to your
> complexity measure ...
>
Consider a development project which is a re-implementation of an
existing design on a new platform, where the analysis and designs and
all levels are portable, but the code must be completely re-written. In
this case, after the platform-dependencies have been isolated and
factored out, the function points should be approximately equivalent.
Factors in the lines of code generated will include coding style,
implementation languages, embedded commentary and on-line help,
initialization methods, etc. In addition, even the methods of counting
lines may be incommensurable, when different languages are compared.
When external libraries are used, it is pointless to even guess at the
number of source lines, but the number of function points may be
estimated with somewhat more accuracy.
IMHO, comparing SLOC with FP as tools for estimating development effort
is about the same as comparing a wet finger to a weather station, as a
means of determining the current meteorological conditions.
Regards,
--
|=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=|
| Link Hochnadel
| Opinions expressed are not necessarily those of anybody else ...
|=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=/=*=|
Ulf Dextegen
Myself I once produced 8 KLOC of C in one month, surprisingly few
bugs (but then I generally write `simple' code), and abselotely
NO documentation (done by another guy)...
--Ulf Dextegen
Proventek Mindcraft
Ted Wood wrote:
>
> In article <v6wM3.1071$b84.1...@ptah.visi.com>,
> she...@visi.com (Steve Sheldon) wrote:
>
> > About 1500 lines per day on average.
> >
>
> You may mock. I've got a guy assigned to my team for the next project
> who claims to be able to write 20-40 KLOCs of C a month. Oh, and he
> feels that documentation is "a management issue"....
>
Ted Wood
Ulf Dextegen <qtx...@etxb.ericsson.se> wrote:
> Anyone with that approach is a danger to the product/project !!!
That was pretty much my point. The problem is that management (who think
that software is something you buy by the kilo)are listening to this guy
and asking why the rest of us are not so productive.
Cheers
TW
--
Any views expressed in this message are those of
the individual sender, except where the sender
specifically states them to be the views of
Ronald E Jeffries
wrote:
>Can someone give a hint on how many lines of code a programmer can
>produce a day. I know that this depends on the language etc, but I´m
>most interested in C/C++.
>I would appreciate if someone could give a reference to a webpage or
>book.
>
>Thank you.
>
>Ingo
The evidence is that developers produce a near-constant amount of
functionality per day in any language.
However, since most of the really good changes to a program involve
removing code, lines per day is a really bad thing to measure. You get
what you measure ... and you don't want lines of code, you want
function. Measure function.
Relatedly, now that you're measuring function, note that no one else's
numbers have any relationship to your own. They are your own
programmers, your own problems, your own measures. You can't look at
some other group of programmers working some other problem and measure
yourself by them.
Regards,
Ron Jeffries
http://www.XProgramming.com
Disclaimer: I could be wrong -- but I'm not.
(Eagles, "Victim of Love")
Ted Wood
Ronald E Jeffries <ronje...@acm.org> wrote:
> The evidence is that developers produce a near-constant amount of
> functionality per day in any language.
>
> However, since most of the really good changes to a program involve
> removing code, lines per day is a really bad thing to measure. You get
> what you measure ... and you don't want lines of code, you want
> function. Measure function.
>
> Relatedly, now that you're measuring function, note that no one else's
> numbers have any relationship to your own. They are your own
> programmers, your own problems, your own measures. You can't look at
> some other group of programmers working some other problem and measure
> yourself by them.
>
Completely sensible advice. No arguments with this whatsoever.
However PHBs tend to want absolute metrics. If only so they can brag to
other PHBs within the group about how good their guys are. Its one of
those touchy-feely problems that engineers (generalises wildly) are so
bad at solving. You can tell them why you can only give them relative
metrics until 1==0 but they can't then go to the board, who are even
further removed from the problem, and pass that on. It makes them look
like they're not in control, and that is one illusion that managers most
definitely do like to preserve.
Cheers
TW
--
Any views expressed in this message are those of
the individual sender, except where the sender
specifically states them to be the views of Sortex Ltd.
Ulf Dextegen
Management issue indeed...
I recall a mission at a large Canadian telecom company,
where a middle-level manager set individual salary increase
by the number of bugs his staff busted...
So the collegue who fixed the easy 50 problems that year
got a bigger increase than the guy who fixed only 5.
No consideration at all to the fact that the `5-person'
fixed the impossible reports that had been open for a couple
of years (since no one else dared to touch them)...
...he resigned the next year...
David Alex Lamb
Mark Johnson <mark.j...@symbios.com> wrote:
>The classic 'bogey' figure has always been 10 lines per programmer-day
>of fully documented and tested source code, including design, code,
>debug, and unit/module test. Most authorities who cite this figure contend
>that it is relatively independent of programming language, which of
>course implies that higher level languages are more productive.
"Programming Productivity", a now-out-of-print book by T. Capers Jones, had
quite a bit on making this sort of measure reasonable. To your list of
things-to-be-included he also added that you need to take into account
cancelled projects. Thus if you measure 15 LOC per day and 1/3 of projects
are cancelled, your effective rate is 10 LOC per day.
I imagine IFPUG has some data on "function points per day" as an alternative
measure.
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/
Peter Leeson
writes:
>I can just picture you doing this research for a manager "just for his or
>her own edification" with within a few days or weeks everyone being made to
>show their "X lines" for the day or week.
When you start measuring, remember that the managerss job is to make sure their
staff is working efficiently. If they find out that their staff is not been
productive, it is only a measurement of their own productivity.
Peter Leeson
Jason Che-han Yip
> Note that the only meaningful use of the LOC/day count is to apply it to
> _delivered_ code. You need to account for test harnesses, prototypes,
> blind alleys, debugging time, etc... This is why you see so many
> figures in the 5-15 LOC/Day range.
I'm currently working through PSP 1.0 and I'm averaging 18 Total New &
Changed LOC/hour (counting semi-colons in Java and only includes new,
modified, and deleted LOC). This includes all stages from planning to
postmortem (i.e. writing test class, fixing defects, all the PSP reports,
etc.).
There's still a problem with a manager with using such a number for
productivity though since reused LOC won't be included. The absolute time
that Person A takes to finish a unit of functionality could be less than
Person B and Person A can still have lower LOC/hour numbers. This could be
due to reuse, better process, whatever.
It's really only useful to compare against itself so that you can
quantitatively judge the effects of process changes.
In any case, I'm still not sure where all the extra time comes in to make it
5-15 LOC/Day? Is this because the time for the planning and documentation
of the overall project is taken into account?
randy c ford
>
> I'm currently working through PSP 1.0 and I'm averaging 18 Total New &
> Changed LOC/hour (counting semi-colons in Java and only includes new,
> modified, and deleted LOC). This includes all stages from planning to
> postmortem (i.e. writing test class, fixing defects, all the PSP
> reports, etc.).
> In any case, I'm still not sure where all the extra time comes in to
> make it 5-15 LOC/Day? Is this because the time for the planning and
> documentation of the overall project is taken into account?
The LOC in 5-15 LOC/Day only counts lines of code that actually make it
into the final project. The Day includes the time of everyone working
on the project, including testers, tech writers, etc.
--
randy
ra...@null.net
Ronald E Jeffries
<robert...@tait.co.nz> wrote:
>If you want to measure yourself, there is nothing wrong with LoC. If you
>want to compare your rates with other
>people be VERY VERY careful about LoC.
Actually, there is something wrong with LoC.
More LoC is not better than less LoC. IMO LoC is simply NOT a useful
metric for any purpose whatsoever.
Robert Searle
all lines written as test harnesses
drivers. In my experience there can be as much test code as deleivered.
If you want to measure yourself, there is nothing wrong with LoC. If you
want to compare your rates with other
people be VERY VERY careful about LoC.
Jason Che-han Yip
> On Fri, 22 Oct 1999 10:21:52 +1300, Robert Searle
> <robert...@tait.co.nz> wrote:
>
> >If you want to measure yourself, there is nothing wrong with LoC. If you
> >want to compare your rates with other
> >people be VERY VERY careful about LoC.
>
> Actually, there is something wrong with LoC.
>
> More LoC is not better than less LoC. IMO LoC is simply NOT a useful
> metric for any purpose whatsoever.
I wouldn't go that far. LOC (with a counting standard) is an objective size
measure that can be automatically counted and independently verified. You
can't say the same for subjective measures like function points. If you're
going to be doing quantitative empirical studies, you're going to be using
LOC.
LOC is a size measure. I'd agree that it is absurd to say the larger the
LOC, the "better" the program.
The usefulness of LOC/hour or LOC/day, beyond measuring against yourself, is
questionable.
Jason Che-han Yip
> Jason Che-han Yip <jch...@ucalgary.ca> wrote:
>
> >I wouldn't go that far. LOC (with a counting standard) is an objective size
> >measure that can be automatically counted and independently verified.
>
> And yet meaningless. Just because something is easy to measure and easy to
> verify doesn't mean that measuring that attribute will yield anything
> meaningful. The amount of body hair I leave lying around in my office would
> be easy to measure. What that has to do with my productivity I'm not sure.
> But it's quantifiable and measurable.
Ron had said:
"More LoC is not better than less LoC. IMO LoC is simply NOT a useful
metric for any purpose whatsoever."
I'd like to emphasize "any purpose"
My response included the statement "LOC is a size measure". My point was that
LOC (with a counting standard) is useful for the purpose of objectively measuring
size.
I'd like to emphasize "size measure".
LOC is not a productivity measure. LOC/hour or LOC/day may be considered a
productivity measure.
I had also said that "the usefulness of LOC/hour or LOC/day, beyond measuring
against yourself, is questionable." LOC/hour used as a productivity measure in
order to improve my personal process seems to be quite meaningful. LOC/hour or
LOC/day to measure people against each other or even to try to estimate how long
a group of developers will take to develop something is probably not meaningful
at all.
I personally prefer the approach of each developer telling the project manager
how long s/he is going to take to complete a particular task.
randy c ford
>
> On Fri, 22 Oct 1999 10:21:52 +1300, Robert Searle
> <robert...@tait.co.nz> wrote:
>
> metric for any purpose whatsoever.
>
I use LOC to help determine the effort that will be required when
bringing a system in-house. An application that has 100,000 LOC
probably won't take as much effort to maintain as one that has 1,000,000
LOC, if they are otherwise similar. Of course, number of modules,
number of functions of modules, size of each module, size of each
function, number of defects outstanding, age of defects, number of
defects fixed in the last year, and a lot of other metrics are also
important.
I agree that LOC/time interval is close to useless as a productivity
measure. If I were to be graded by LOC, I would ensure that I was very
'productive' by making decisions on how to code that would show me to be
productive. Without being graded by that, I focus on how to really be
more productive. You get what you measure.
I wonder if LOC/function point would be meaningful? If it were applied
to people or groups, it would become meaningless; using it to measure
development environments could be interesting. (How do you deal with
generated code? It is not optimized to reduce LOC. You'd have to find
a way to measure some equivilent of LOC to the input to the tool.)
--
randy
ra...@null.net
Scott P. Duncan
> Ron had said:
> "More LoC is not better than less LoC. IMO LoC is simply NOT a useful
> metric for any purpose whatsoever."
> My response included the statement "LOC is a size measure". My point was that
> LOC (with a counting standard) is useful for the purpose of objectively measuring
> size.
>
> I'd like to emphasize "size measure".
>
> LOC is not a productivity measure. LOC/hour or LOC/day may be considered a
> productivity measure.
In general, I think you could fairly say that LOC, in the numerator of a
metric, is likely questionable if not downright useless, while LOC, in
the denominator of a metric, can be useful within a given organization.
Hence, defects/KLOC can be of some value and, as noted, can be more
easily computed with consistency based on simpler counting rules than
other size measures. [Though, if one really commits to an effective
measurement program, then a size measure based on functionality, not
bulk, will be a better way to go since it will expand the range of useful
metrics you can expect to engage in.]
--
Scott P. Duncan
SoftQual Consulting http://www.mindspring.com/~softqual/
Jason Che-han Yip
> In general, I think you could fairly say that LOC, in the numerator of a
> metric, is likely questionable if not downright useless, while LOC, in
> the denominator of a metric, can be useful within a given organization.
> Hence, defects/KLOC can be of some value and, as noted, can be more
> easily computed with consistency based on simpler counting rules than
> other size measures. [Though, if one really commits to an effective
I don't see how the usefulness of LOC depends on whether it is in the numerator or the
denominator. defects/KLOC can be misinterpreted and/or faked out just as easily as
KLOC/hour.
> measurement program, then a size measure based on functionality, not
> bulk, will be a better way to go since it will expand the range of useful
> metrics you can expect to engage in.]
I'm not sure what you mean by this last sentence? How does functionality-based size
measure expand the range of useful metrics?
Customers talk in features, functionality, stories and not LOC so it would seem to be a
better idea to learn how to estimate based on features, functionality, stories.
However, you can also use features, functionality, stories as proxies for LOC. Whether
this improves estimation ability sufficiently for it to be worth the effort is another
issue.
Suresh Nageswaran
One question on LOC :
What is the actual method by which LOC is ascertained / measured ? i believe
a fundamental definition of a LOC is difficult. In languages like C one can
write entire programs in a single "line", if a LOC can be considered
demarcated by a semicolon.
But without a measure like LOC, we cant apply Putnam's equation to a
practical effort estimation of a project. So how is this really done ? In my
company, we dont use any scientific means to calculated the effort
involved - it's mostly developer experience which we rely on to chart out
estimates. It's not the way I learnt it at engineering school - and thats
the whole problem.
Estimation Ubergurus, please shed some light !
-Suresh
Jason Che-han Yip wrote in message <38108E80...@ucalgary.ca>...
>Ronald E Jeffries wrote:
>
>> On Fri, 22 Oct 1999 10:21:52 +1300, Robert Searle
>> <robert...@tait.co.nz> wrote:
>>
>> >If you want to measure yourself, there is nothing wrong with LoC. If you
>> >want to compare your rates with other
>> >people be VERY VERY careful about LoC.
>>
>> Actually, there is something wrong with LoC.
>>
>> More LoC is not better than less LoC. IMO LoC is simply NOT a useful
>> metric for any purpose whatsoever.
>
>I wouldn't go that far. LOC (with a counting standard) is an objective
size
>measure that can be automatically counted and independently verified. You
>can't say the same for subjective measures like function points. If you're
>going to be doing quantitative empirical studies, you're going to be using
>LOC.
>
>LOC is a size measure. I'd agree that it is absurd to say the larger the
>LOC, the "better" the program.
>
>The usefulness of LOC/hour or LOC/day, beyond measuring against yourself,
is
>questionable.
>
>
Jason Che-han Yip
> One question on LOC :
>
> What is the actual method by which LOC is ascertained / measured ? i believe
> a fundamental definition of a LOC is difficult. In languages like C one can
> write entire programs in a single "line", if a LOC can be considered
> demarcated by a semicolon.
There is no fundamental definition of LOC that I know of. LOC should be in
relation to both a LOC counting standard AND a coding standard. Beyond that,
I'd say pick whatever counting standard you find useful (i.e. correlates well
enough with time)
> But without a measure like LOC, we cant apply Putnam's equation to a
> practical effort estimation of a project. So how is this really done ? In my
> company, we dont use any scientific means to calculated the effort
> involved - it's mostly developer experience which we rely on to chart out
> estimates. It's not the way I learnt it at engineering school - and thats
> the whole problem.
If developer experience estimation is accurate enough, I don't see why it would
be necessary to go to more "scientific" approaches.
> Estimation Ubergurus, please shed some light !
I'm definitely not an estimation "uberguru", just another poor soul going
through the PSP...
Khuong Le
Thanks
Jason Che-han Yip wrote:
Ronald E Jeffries wrote:> On Fri, 22 Oct 1999 10:21:52 +1300, Robert Searle
> <robert...@tait.co.nz> wrote:
>
> >If you want to measure yourself, there is nothing wrong with LoC. If you
> >want to compare your rates with other
> >people be VERY VERY careful about LoC.
>
> Actually, there is something wrong with LoC.
>
> More LoC is not better than less LoC. IMO LoC is simply NOT a useful
> metric for any purpose whatsoever.I wouldn't go that far. LOC (with a counting standard) is an objective size
measure that can be automatically counted and independently verified. You
can't say the same for subjective measures like function points. If you're
going to be doing quantitative empirical studies, you're going to be using
LOC.LOC is a size measure. I'd agree that it is absurd to say the larger the
LOC, the "better" the program.The usefulness of LOC/hour or LOC/day, beyond measuring against yourself, is
questionable.
-- Khuong -- Sr. Software Engineer Fujitsu Network Communications mailto:khuo...@fnc.fujitsu.com
Link Hochnadel
>
> One question on LOC :
>
> What is the actual method by which LOC is ascertained / measured ? i believe
> a fundamental definition of a LOC is difficult. In languages like C one can
> write entire programs in a single "line", if a LOC can be considered
> demarcated by a semicolon.
>
> practical effort estimation of a project. So how is this really done ? In my
> company, we dont use any scientific means to calculated the effort
> involved - it's mostly developer experience which we rely on to chart out
> estimates. It's not the way I learnt it at engineering school - and thats
> the whole problem.
>
>
>
Briefly,
1) See www.ifpug.org!
2) Stop counting LOCs, SLOCs, KLOCs, and CROCs!
3) Start counting function points (FPs)!
There seem to be at least three major schools of thought about technical
methodology of counting FPs, but the language issues (e.g. "how many
lines of assembler are equal to a line of C++") becomes moot, whichever
school you adopt. That is, the methods produce more clearly comparable
results, on different scales.
The International Function Point Users Group (ifpug) has the longest
tradition, and teaches methodology which incorporates some rather
subjective fudge factors, but it has also accumulated a collection of
documented research and empirical studies, which are made available to
its membership.
Counting function points is similar to measuring complexity in a
program, and requires a complete, detailed design for the program to be
written; however, FPs for a project can sometimes be estimated by
reviewing the results from similar developments done by others.
Converting estimates of FPs into estimates of effort, man-hours and LOCs
remains a problem for companies with insufficient development experience
as a team, but the process is more definitive than deriving an estimate
for LOCs from the basis of an unevaluated design.
As a simple example in C, compare the LOC
n=j*p
with the logically equivalent LOC
for ( i=p, n=0 ; i>0 ; i--, n +=j )
The LOC in the second case could be reasonably manipulated to produce
almost any small number less than 10. Counting FP using any of the
extant methods will demonstrate that the second statement has more FPs
than the first by an invariant quantity, regardless of how the code is
formatted or juggled.
Note:
There are many other factors which affect the human effort required to
develop a computer program. Some of these are characteristics of the
computer program, some aren't.
Complexity in code/design, a major factor in effort required to develop
programs, is more accurately accounted when counting FPs than when
counting LOCs.
I'm a Nada guru - I've never experienced nirvana, but I can occasionally
sense nonsense.
Jeffrey C. Dege
>
>--------------8D8DFA003A4B3C0B0BB2D399
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Do you have a program to count lines of C & C++ code?
>
>Thanks
find . -name *.hpp -o -name *.cpp | xargs cat | tr -cd ';' | wc -c
--
Tempore brumali vir patiens.
Animo vernali Lasciviens.
O, o, totus floreo,
jam amore virginali totus ardeo,
novus, novus amor est, quo pereo.
Scott P. Duncan
> I don't see how the usefulness of LOC depends on whether it is in the numerator or the
> denominator. defects/KLOC can be misinterpreted and/or faked out just as easily as
> KLOC/hour.
The denominator of a metric is the bulk value against which the numeratorcompared, so to
speak. It is stated as "numerator by denominator." So,
in effect, you are saying that the numerator is produced/done/etc. by some
rate or volume represented by the denominator.
Hence, KLOC/day suggests a rate of producing lines of code each day
which some would might say is a productivity measure since many
productivity measures are some unit of something produced per some unit
of time. If it is important to produce the numerator as a valid measure of
productivity then such a metric can have value. I feel anything in the
numeratyor can be a target value of something useful to measure/track.
If find KLOC in the numerator not to lead to anything useful if used as
any kind of target value (as a general rule).
On the other hand, defects/KLOC does not suggest that the production of
KLOC is the target. The focus is on defects and it is reasonable to expect
that reducing the number of defects per volume of software produced can
be a good thing to target, again, in general.
It is possible, of course, to deliberately try to manipulate any measure if
you want to do so to try to get the answer someone else expects you to get.
I prefer to implement metrics programs where the use of the data is to
identify trends over time and then to use these to ask what or why a trend
is occurring which is not desirable. To set a numeric target presupposes,
in my view, that the orgaization is sufficiently sophisticated about both its
use of metrics and its ability to assess process behavior that it can know
that, given such a taregt, it can manage it processes to achieve the target.
If you don't have such knowledge and control in place, then mandating a
target, no matter how desirable, is likely futile, at best and, perhaps, a
purely perverse, dysfunctional management tool to manipulate software
development for some short-term purpose that is likely to be, long-term,
disruptive.
> How does functionality-based size
> measure expand the range of useful metrics?
Because productivity measures based on functionality rather than a bulkmeasure like KLOC
is more likely to lead to useful productivity measures.
If you don't use functionality measures, then meaningful productivity
measures are likely not at your disposal.
> Customers talk in features, functionality, stories and not LOC so it would seem to be a
> better idea to learn how to estimate based on features, functionality, stories.
Which is another reason I said what I did above since I agree with this.
> However, you can also use features, functionality, stories as proxies for LOC. Whether
> this improves estimation ability sufficiently for it to be worth the effort is another
> issue.
Putting aside for a moment how one counts either LOC or FPs and assuming
one has, at least within their own organization, a useful standard for this, then
measuring size by FPs rather than LOC will give you a measure that is less
easily manipulated, for good or bad, to produce variations that are not properly
attributed to actual intended software additions/changes.
Scott P. Duncan
Jason Che-han Yip wrote:
> Suresh Nageswaran wrote:
>
> > What is the actual method by which LOC is ascertained / measured ? i believe
> > a fundamental definition of a LOC is difficult.
>
> There is no fundamental definition of LOC that I know of. LOC should be in
> relation to both a LOC counting standard AND a coding standard.
I agree with the last statement. Within that context, there are some
fairly commonly accepted rules, none enforced by any formal group
as FPs are by IFPUG.
For example, Capers Jones, in some of his older books, provides
counting rules for LOC. He much favors FPs these days and has
for a while. But the older rules can be useful.
Most folks I know count "logical" lines, not physical ones, which
means counting statement terminators (e.g., ";"). They also count
non-comment, new and changed lines as their baseline measure,
dealing with deleted lines in some consistent way within their
own organization. If they choose to benchmark against any external
LOC reports, they insist on knowing the other organization's rules.
John Zoltai
"Scott P. Duncan" wrote:
It is possible, of course, to deliberately try to manipulate any measure if
you want to do so to try to get the answer someone else expects you to get.
I prefer to implement metrics programs where the use of the data is to
identify trends over time and then to use these to ask what or why a trend
is occurring which is not desirable. To set a numeric target presupposes,
in my view, that the orgaization is sufficiently sophisticated about both its
use of metrics and its ability to assess process behavior that it can know
that, given such a taregt, it can manage it processes to achieve the target.
And therein lies the key. Like a subdivision homeowner cranking out shacks, a software organization needs to have a set of metrics based on experience with projects of similar scope and function, before they can tell whether they're doing better or worse on a particular job. And like any other organization, the strengths and weaknesses of a software developers internal processes and personnel make it, and the metrics that represent it, unique.
One of the biggest mistakes a software organization can make is to try to apply non-relevant metrics to a new development effort that falls outside the range of experience of the organization. Risks always rise when you step outside your comfort zone.
Putting aside for a moment how one counts either LOC or FPs and assuming
one has, at least within their own organization, a useful standard for this, then
measuring size by FPs rather than LOC will give you a measure that is less
easily manipulated, for good or bad, to produce variations that are not properly
attributed to actual intended software additions/changes.
Function points are also easier to gather from requirements and/or design documents. This makes it easier to estimate the scope of the implementation effort before you actually start.
--
John T. Zoltai, CCP
- Remove shield to email