They say (iirc), you average 25 lines of code a day.

I might have achieved that total over the last month or two.
(thrown away dozens of pages of code)

A graphical text editor with multiple windows that are updated
whenever the text in any single window is changed sounds (and
should be) simple. The low-level interactions between the data
structures for each window is just wicked.

[ Post a follow-up to this message ]

On Thu, 22 Dec 2005 01:56:16 +1100,
Russell Shaw <rjshawN_o@s_pam.netspace.net.au> wrote:
> They say (iirc), you average 25 lines of code a day.

Who says that, and what language were they using at the time?

[ Post a follow-up to this message ]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Thu, 22 Dec 2005 01:56:16 +1100,
> Russell Shaw <rjshawN_o@s_pam.netspace.net.au> wrote: 
>
> Who says that, and what language were they using at the time?

I've heard the figure 10, for any language.  That's why using a
high-level language is more efficient.

--
Måns Rullgård
mru@inprovide.com

[ Post a follow-up to this message ]

On Thu, 22 Dec 2005 10:25:58 +0000, Måns Rullgård <mru@inprovide.com> wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes: 
>
> I've heard the figure 10, for any language.  That's why using a
> high-level language is more efficient.

Having written programs that range from 300 to 3000+ lines of 'code' in
less than a day, including their documentation, functional spec and
manpage, I don't think that's true.

The 'average' may be close to this for a certain period of time and a
large number of people, but even if lines of code was a relatively
useful measure of productivity, I doubt the average is so low, until I
see real numbers :-/

[ Post a follow-up to this message ]

Giorgos Keramidas wrote:
> On Thu, 22 Dec 2005 10:25:58 +0000, M=E5ns Rullg=E5rd <mru@inprovide.com>=
wrote: 
>
> Having written programs that range from 300 to 3000+ lines of 'code' in
> less than a day, including their documentation, functional spec and
> manpage, I don't think that's true.
>
> The 'average' may be close to this for a certain period of time and a
> large number of people, but even if lines of code was a relatively
> useful measure of productivity, I doubt the average is so low, until I
> see real numbers :-/

Greetings,

The number of lines of code written per day per developer is very high
for small projects and very low for large projects.  I once read an
article in Scientific American which states an average of something
like 200 lines per developer per month on very large projects.  Perhaps
someone subscribes to Scientific American online and can verify this
number.  Of course if you are working on a small project you will
realize much higher productivity ... even if that small project is
going to be incorporated into something larger.

Hope this helps,
William

PS: Lines of code per day is in fact one useful measure of
productivity.  However, it is not the only useful measure and can be
very misleading when taken on its own or out of context.

[ Post a follow-up to this message ]

On Thu, 22 Dec 2005 17:36:55 +0200, Giorgos Keramidas wrote:

> Having written programs that range from 300 to 3000+ lines of 'code' in
> less than a day, including their documentation, functional spec and
> manpage, I don't think that's true.

And I would have a hard time believing
" 3000+ lines of 'code' in less than a day,
including their documentation, functional spec and manpage"

> The 'average' may be close to this for a certain period of time and a
> large number of people, but even if lines of code was a relatively
> useful measure of productivity, I doubt the average is so low, until I
> see real numbers :-/

I would hazard the guess that if you total the time spent writing
requirement and design documents, test specs, code, reviewing all the
above, test time, arguing with QA on their test failures, divided by lines o
f
code, you could get the low numbers.

Of course then there is requirement creep during testing.  
No one adds in the time spent doing the weekly report and staff meetings.

Since I was designer and maintenance programmer for a 100,000+ lines of
PLI code making up 80+ applications, it saved time to write programs to
automatically test library modules and applications. Several of the
library test were longer than the code being tested. Glad I was able
to bypass requirement, design, test plan documents for the test code. 

[ Post a follow-up to this message ]

"Bit Twister" <BitTwister@mouse-potato.com> wrote in message
news:slrndqls06.27g.BitTwister@wb.home.invalid...

> I would hazard the guess that if you total the time spent writing
> requirement and design documents, test specs, code, reviewing all the
> above, test time, arguing with QA on their test failures, divided by lines
> of
> code, you could get the low numbers.

You typically get about 40 lines a day. The equation is lines of code
divided by days taken divided by number of people working on the project.
The number of days should start when the basic functional specification is
done (that is, when everyone knows what the code is supposed to do from the
end user's point of view) and end when the code is of sufficient quality to
be released.

DS

[ Post a follow-up to this message ]

Bit Twister wrote:
> On Thu, 22 Dec 2005 17:36:55 +0200, Giorgos Keramidas wrote:
>
> 
>
>
> And I would have a hard time believing
>     " 3000+ lines of 'code' in less than a day,
>       including their documentation, functional spec and manpage"

I think that's because the two of you are mixing apples and oranges.

Expected LOC/person/period depends on what is required of the final
product.  That is upon the rigor and discipline of the development
environment.  It also depends a lot on how you define a "line of code"
and how you measure.  It also depends on how you consider lines of
reused code.

For example, you mention QA below.  Many shops have no independent
QA/QC testing.  Most have very little rigor at all.  If your dev
process includes QA testing and Giorgos' doesn't then you would
consider Giorgos' LOC prodictivity to be ZERO while he considers it
much higher.

Most software shops ship to customers what rigorous shops would
consider beta or even alpha versions.  Most would consider the project
finished when the rigorous shops would consider it in mid development
for at least another release cycle.  Productivity metric are going to
vary widely between the two types of development environments.

-- ced

>
> 
>
>
> I would hazard the guess that if you total the time spent writing
> requirement and design documents, test specs, code, reviewing all the
> above, test time, arguing with QA on their test failures, divided by lines
 of
> code, you could get the low numbers.
>
> Of course then there is requirement creep during testing.  
> No one adds in the time spent doing the weekly report and staff meetings.
>
> Since I was designer and maintenance programmer for a 100,000+ lines of
> PLI code making up 80+ applications, it saved time to write programs to
> automatically test library modules and applications. Several of the
> library test were longer than the code being tested. Glad I was able
> to bypass requirement, design, test plan documents for the test code. 


--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

[ Post a follow-up to this message ]

>> And I would have a hard time believing 
>
>I think that's because the two of you are mixing apples and oranges.
>
>Expected LOC/person/period depends on what is required of the final
>product.

Does it require debugging?  MIL-STD-whatever flowcharting and documention?

>That is upon the rigor and discipline of the development
>environment.  It also depends a lot on how you define a "line of code"
>and how you measure.  It also depends on how you consider lines of
>reused code.

If you pay by the lines of code, you will get lots of lines of code:

# \
include \
<stdio.h>
int
main
(
int
argc
,
char
*
*
argv
}
{
printf
(
"H"
"e"
"l"
"l"
"o"
","
" "
"w"
"o"
"r"
"l"
"d"
"\n"
)
;
return
0
;
}

I hope nobody is willing to pay for unlimited *blank* lines.  Or
including a copy of the specification document as a comment in EVERY
source file.  A *good* definition of LOC will probably need a lawyer
to interpret it, but it will be much harder for someone to just run
a "LOC maximizer" program on their code and get results like the
one above (e.g. changing all occurrences of white space to newline,
except within quotes and a few other places where it changes the
meaning or isn't allowed).  The definition should assume people
will try to cheat and close the loopholes.

>For example, you mention QA below.  Many shops have no independent
>QA/QC testing.  Most have very little rigor at all.  If your dev
>process includes QA testing and Giorgos' doesn't then you would
>consider Giorgos' LOC prodictivity to be ZERO while he considers it
>much higher.
>
>Most software shops ship to customers what rigorous shops would
>consider beta or even alpha versions.

I think Windows 3.1 qualified for having been shipped before it
was designed.  And there's a lot of software out there that
qualifies as having shipped in "pre-prototype" state (e.g.
it was shipped before anyone checked whether the first link
had any undefined symbols.)

>Most would consider the project
>finished when the rigorous shops would consider it in mid development
>for at least another release cycle.  Productivity metric are going to
>vary widely between the two types of development environments.

Gordon L. Burditt

[ Post a follow-up to this message ]

MIL-spec calls for 15 lines of code per day, based on design, coding, debugg
ing, testing,
documentation and systems integration.  Curiously, the number of lines is pr
etty
independent of the language (for various ways of counting "lines"), hence th
e military's
propensity for high-level languages.


--
#include <standard.disclaimer>
_
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up

[ Post a follow-up to this message ]