Software Engineering - Where did I read that productivity study?!

Author

Where did I read that productivity study?!

Mike Silva

2006-09-12, 7:02 pm

Hello all,

A few w

s ago I ran across a link to a study about how much software
(SLOC) could be produced by a team in a year. If I remember the
figures right, team productivity declined after about 70,000 or 75,000
SLOC per year, with teams of 3 to 10 programmers, although larger teams
(up to 40 members IIRC) could produce up to 180,000 SLOC per year at a
cost multiplier of between 1.5 (or 1.25) and 3.9. Again, all of these
are vaguely remembered figures. Problem is, I can't remember how or
where I found the study. Might have been linked in a newsgroup
article, but I can't be sure.

Anyway, does this study ring a bell? I'd like to find it again, and
have enough sense to bookmark it if it is as interesting as I vaguely
recall that it was. Many thanks!

Phlip

2006-09-12, 7:02 pm

Mike Silva wrote:

> A few w

s ago I ran across a link to a study about how much software
> (SLOC) could be produced by a team in a year.

Oh, Cod, another LOC thread.

Hie thee hence to news:comp.programming and read the last one, and read the
start of the "programmer productivity" thread.

Counting lines to measure progress is widely regarded as an AntiPattern...

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

xpyttl

2006-09-12, 9:59 pm

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:wSINg.654$e66.574@newssvr13.news.prodigy.com...

> Counting lines to measure progress is widely regarded as an AntiPattern...

Only by the anti-productivity crowd

LOC may not be a particularly good measure, but it is a LOT better than no
measure.

...

Mike Silva

2006-09-12, 9:59 pm

Phlip wrote:
> Mike Silva wrote:
>
>
> Oh, Cod, another LOC thread.
>
> Hie thee hence to news:comp.programming and read the last one, and read the
> start of the "programmer productivity" thread.

Already read it. I still want to find that study. I'm just
incorrigible.

Pascal Bourguignon

2006-09-13, 4:00 am

"Phlip" <phlipcpp@yahoo.com> writes:

> Mike Silva wrote:
>
>
> Oh, Cod, another LOC thread.
>
> Hie thee hence to news:comp.programming and read the last one, and read the
> start of the "programmer productivity" thread.
>
> Counting lines to measure progress is widely regarded as an AntiPattern...

We all agree. But it's still interesting, for big projects who can
gather a lot of numbers. It would be as interesting (and as funny
too), if they extracted statistics on the shoelace lengths or tie
length too.

Perhaps the team with the shortests shoelaces can produce more LOC too?

--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

Richard Heathfield

2006-09-13, 4:00 am

Pascal Bourguignon said:

> "Phlip" <phlipcpp@yahoo.com> writes:
>
>
> We all agree. But it's still interesting, for big projects who can
> gather a lot of numbers. It would be as interesting (and as funny
> too), if they extracted statistics on the shoelace lengths or tie
> length too.
>
> Perhaps the team with the shortests shoelaces can produce more LOC too?

The team with the shortest shoelaces will comprise the people who think
shoelaces are a complete waste of time, and who therefore wear slip-ons.
These people are also likely to think that LOC-counting is a complete waste
of time. But they are /also/ likely to think that if LOCs are being used as
a productivity measure, they can get paid more for writing code generators
than for writing code. Consider the very complex task of defining and
initialising a string, which is certainly a coding challenge worthy of
recognition by the LOC counters:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
int rc = EXIT_FAILURE;

if(argc < 3)
{
puts("Duffer! Argue more");
}
else
{
int i;
int t = strtol(argv[2], NULL, 10);
printf(" char s[] =\n {\n");
for(i = 0; i < t; i++)
{
printf(" '\\0'%s /* ; */\n", i < (t - 1) ? "," : " ");
}
printf(" };\n");
}
return rc;
}

Note the commenting, which hedges against those mean-spirited souls who
count semicolons rather than newlines!

(The bean-counters' next line of attack is to custom-indent and *preprocess*
the source before doing the line-counting...)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

S Perryman

2006-09-13, 8:00 am

"Richard Heathfield" <invalid@invalid.invalid> wrote in message
news:59KdnXUVU-BtT5rYRVnyjQ@bt.com...

> Pascal Bourguignon said:

[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> The team with the shortest shoelaces will comprise the people who think
> shoelaces are a complete waste of time, and who therefore wear slip-ons.
> These people are also likely to think that LOC-counting is a complete
> waste
> of time. But they are /also/ likely to think that if LOCs are being used
> as
> a productivity measure, they can get paid more for writing code generators
> than for writing code. Consider the very complex task of defining and
> initialising a string, which is certainly a coding challenge worthy of
> recognition by the LOC counters:

> #include <stdio.h>
> #include <stdlib.h>

> int main(int argc, char **argv)
> {
> int rc = EXIT_FAILURE;

> if(argc < 3)
> {
> puts("Duffer! Argue more");
> }
> else
> {
> int i;
> int t = strtol(argv[2], NULL, 10);
> printf(" char s[] =\n {\n");
> for(i = 0; i < t; i++)
> {
> printf(" '\\0'%s /* ; */\n", i < (t - 1) ? "," : " ");
> }
> printf(" };\n");
> }
> return rc;
> }

> Note the commenting, which hedges against those mean-spirited souls who
> count semicolons rather than newlines!

My very simple generic LOC scripts would give an NLOC ( 'normalised'
LOC) of 14 for the above example. Considering the original text is 24 lines
long, IMHO that is a reasonable assessment of the code by such very simple
scripts.

Regards,
Steven Perryman

Steve O'Hara-Smith

2006-09-13, 8:00 am

On Wed, 13 Sep 2006 11:07:56 +0200
Pascal Bourguignon <pjb@informatimago.com> wrote:

> We all agree. But it's still interesting, for big projects who can
> gather a lot of numbers. It would be as interesting (and as funny
> too), if they extracted statistics on the shoelace lengths or tie
> length too.

Beard and hair length might be more appropriate :)

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

Richard Heathfield

2006-09-13, 8:00 am

S Perryman said:

> "Richard Heathfield" <invalid@invalid.invalid> wrote in message
> news:59KdnXUVU-BtT5rYRVnyjQ@bt.com...
>
>
>
>
<code generator snipped>
>
> My very simple generic LOC scripts would give an NLOC ( 'normalised'
> LOC) of 14 for the above example. Considering the original text is 24
> lines long, IMHO that is a reasonable assessment of the code by such very
> simple scripts.

I think you didn't run the program. (I note that it had a bug, btw! It was
always using s, instead of argv[1]. Fixed for following demo.)

Boss: we need a string, urgently!
Joe Lochacker: sure - how long?
Boss: 32 bytes. How long?
Joe Lochacker (trying not to laugh): Hmmm, big string, so it's gonna take
time to initialise correctly - give me two or three minutes on that...

joe@trix:~/dev> strgen BossString 32
char BossString[] =
{
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0' /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0', /* ; */
'\0' /* ; */
};

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

S Perryman

2006-09-13, 8:00 am

"Richard Heathfield" <invalid@invalid.invalid> wrote in message
news:VZydnZe2zY0AdprYnZ2dnUVZ8sidnZ2d@bt
.com...

>S Perryman said:

> <code generator snipped>

[color=darkred]
> I think you didn't run the program. (I note that it had a bug, btw! It was
> always using s, instead of argv[1]. Fixed for following demo.)

The NLOC would still be smaller than the size as generated by your program
(the braces are discounted) .

Fortunately, complementary processes (code inspection/review etc) can
easily discover the pathological nastiness in your example and its kin. :-)

As an aside, it does lead to the interesting question of LOC measures for
tool-generated code. Some (by design etc) go for obsfucation, others for
more readable layout.

Regards,
Steven Perryman

Richard Heathfield

2006-09-13, 8:00 am

S Perryman said:

<snip>

> The NLOC would still be smaller than the size as generated by your program
> (the braces are discounted) .

Sure, but what's a couple of braces between friends, when we can generate
over 10,000 lines of code for a definition of a 10KB string? Yes, you could
count semicolons, but my hack took that into account. So next you
preprocess the code to rip out comments. But that still leaves you open to
code like this:

for(;0;);;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Fortunately, complementary processes (code inspection/review etc) can
> easily discover the pathological nastiness in your example and its kin.
> :-)

Well, one would hope so. But the semicolon hack is insidious, since spurious
semicolons are easily buried. If someone wanted to rig the count, and the
LOC counter counted semicolons, it would be trivial to inflate one's
"productivity"(!) metric. Let me grab some arbitrary code:

int wl_resize(wordlist *w, size_t newsize)
{
int rc = 1; /* fail */
size_t n = w->max;
char **new = realloc(w->word, newsize * sizeof *new);
if(new != NULL)
{
w->word = new;
while(n < newsize)
{
w->word[n++] = NULL;
}
w->max = newsize;
rc = 0; /* pass */
}
return rc;
}

Productivity metric: 8

int wl_resize(wordlist *w, size_t newsize)
{
int rc = 1; /* fail */
size_t n = w->max;;
char **new = realloc(w->word, newsize * sizeof *new);;
if(new != NULL)
{
w->word = new;;
while(n < newsize)
{
w->word[n++] = NULL;;
}
w->max = newsize;;
rc = 0;; /* pass */
}
return rc;;
}

Productivity metric: 15

I guess I was working twice as hard the second time.

> As an aside, it does lead to the interesting question of LOC measures for
> tool-generated code. Some (by design etc) go for obsfucation, others for
> more readable layout.

If LOC has any value at all as a productivity measure (which it doesn't, but
never mind that), it is surely for measuring the work output of humans.
Computers don't need to be paid! So LOC-ing code that the bean-counter
*knows* to be autogenerated is a bit of a waste of time, really.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

CBFalconer

2006-09-13, 7:01 pm

Pascal Bourguignon wrote:
> "Phlip" <phlipcpp@yahoo.com> writes:
>
.... snip ...
>
> We all agree. But it's still interesting, for big projects who can
> gather a lot of numbers. It would be as interesting (and as funny
> too), if they extracted statistics on the shoelace lengths or tie
> length too.
>
> Perhaps the team with the shortests shoelaces can produce more LOC too?

I wear sandals most of the time.

--
"I was born lazy. I am no lazier now than I was forty years
ago, but that is because I reached the limit forty years ago.
You can't go beyond possibility." -- Mark Twain

--
Posted via a free Usenet account from http://www.teranews.com

H. S. Lahman

2006-09-14, 7:00 pm

Responding to Silva...

> A few w

s ago I ran across a link to a study about how much software
> (SLOC) could be produced by a team in a year. If I remember the
> figures right, team productivity declined after about 70,000 or 75,000
> SLOC per year, with teams of 3 to 10 programmers, although larger teams
> (up to 40 members IIRC) could produce up to 180,000 SLOC per year at a
> cost multiplier of between 1.5 (or 1.25) and 3.9. Again, all of these
> are vaguely remembered figures. Problem is, I can't remember how or
> where I found the study. Might have been linked in a newsgroup
> article, but I can't be sure.

I don't know which one that might have been. However, Steve Tockey at
Construx investigated the effects of team size on productivity several
years ago. I reviewed the paper but I have no idea where he eventually
placed it. So you might google him or contact him directly about it.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Mike Silva

2006-09-16, 7:59 am

FWIW, a good soul on comp.arch.embedded found the paper for me:

http://www.qsm.com/Develop_12%20months.pdf

Peter Amey

2006-09-18, 7:59 am

Mike Silva wrote:
> Hello all,
>
> A few w

Sponsored Links