How many lines of code per day should a good programmer produce?

[Angus]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

 

[Phlip]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day.

The juniors around me can write 30 to 40 lines per day, but I'm a grizzled
senior so I only write like 5 or 10.

 

[Phlip]

What counts is the *quality* of that code, not its amount. I would
prefer doing 200 lines of extremely high-quality code in 1 week than to
make 500 lines of crappy code in one day.

I delete 20 to 50 lines of code per day...

 

[Victor Bazarov]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day.

If this is a question (I would have liked a question mark at the end
of one), then the answer is "no, there isn't".

I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

It depends. Show us what you "know out", and we can tell. Of course,
in order for me to review your code, I need to be compensated. And,
no, a sample 200 lines won't do. You need to show us at least 2000 LOC
to make the review meaningful.

Or is this benchmakr a bit of a waste of time?

A benchmark is a benchmark; once obtained it might have its use some
day. However, without a target use, obtaining such a benchmark _can_
be viewed as a waste of time. And I don't think there is such a thing
as "a bit of a waste of time". It's either a waste of time or it is
not.

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

Try posting to 'comp.software-eng'. That's where discussions like this
belong.

V

 

[Puppet_Sock]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

How long is a piece of string?

There are many levels of quality of computer code. Stuff
that that is intended strictly for personal use, on a "code
and forget" kind of basis would probably be the lowest.
You write something to do a task, finish the task, and
forget the code. When you do that sort of thing, 200
lines a day isn't bad. But the expectation is, the quality
will be low. You might do this sort of thing when, for
example, you had one 10 megabyte file that needed some
complex reformatting. Say you needed to migrate *one* old
file to a new spec on a new system.

The next level is code that gets passed between developers,
never gets sold, and is only documented at the most trivial
of levels. Often as hand-scribbled notes, photocopied and
passed along with the source. That would be logon scripts
and the like.

The next level is a minimal "internal to the company"
package. It has a formal documentation set, but only of
a minimal sort. It has some level of testing and QA. The
product is still only intended for other developers, but
now it's a (slightly) formal product. This is about the
level of Gnu "for developer" products. Users are expected
to have some degree of expertise in the subject, and make
significant effort to use the app.

The next level is a sem-formal product.
It gets some official docs, testing, QA, etc. And there is
a user manual intended for use by non-developers. This is
about the level of typical shareware products. Users are
expected to have some sophistication, but are not expected
to do any significant "under the hood" sort of stuff.

The next level is a commercial product released for the
general public. It has formal specs, user manual, testing,
QA, install scripts, self diagnostics, etc. All the stuff
you need to "shrink wrap" a product.

Each of these steps is expected to multiply the effort
"per line" by about a factor of 3. Though, the farther
along you go the more non-developers can be used to help
do the work.

Typing in 200 lines of code isn't a big deal. The hard
effort, the time consuming stuff, is the design of the
app, including the spec, the testing schemes, the
prototypical data sets, the general architecture, and
so on. Other quite time intense tasks are testing,
documentation, QA, and such like.

Generally, commercial code usually takes something round
about one person hour per line of shipped code.
Socks

 

[Juha Nieminen]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

Counting programming productivity by number of lines written is
completely nonsensical.

What counts is the *quality* of that code, not its amount. I would
prefer doing 200 lines of extremely high-quality code in 1 week than to
make 500 lines of crappy code in one day.

Of course measuring the quality of the code is pretty difficult, so
even trying to benchmark productivity is quite difficult.

 

[werasm]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

I don't know. All I can say is not too long ago there were to
programmers in our team (they did one of our GUI's in QT) that
could produce an immense amount of code by cutting an pasting (They
were not exactly in my team, so I realized this too late). The
managers were mighty pleased and the GUIs were quite impressive
at first. Then the client required changes. I noticed that
the one guy always burnt the midnight oil. Now I know why.

OTOH I recently (very recently) worked with a guy that opened
my eyes wrt. template metaprogramming. This guy could literally
generate code. He had the ability to think recursively to the
point where I became frustrated with myself. He also had the
ability to hide the ugly tmp things quite nicely. Took him
about a week to write a hundred lines (maybe I'm exaggerating
here). He could handle requirements changes quite quickly as
well. Nevertheless, I did not like maintaining his code.

Or is this benchmakr a bit of a waste of time?

What does one want to achieve with a benchmark like this? You could
probably compare the complexity of projects, but there as so many
other
variables. I suppose this could be a variable, but in general I think
managers over-estimate its value (especially for C++ code).

Regards,

Werner

 

[LordOfThePi]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

LOC is bollocks.

Debug-build object code size (given a specific CPU) can be meaningful,
but only after all testing (including integration) has been passed.

Habitual cut-and-pasters must be terminated with extreme prejudice.

 

[Keith Davies]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

On a *good* day I *remove* LOC, sometimes in the hundreds.

Or is this benchmakr a bit of a waste of time?

Quite. It's not that hard to generate *huge* LOC in a day. Sometimes
the LOC produced are actually useful and appropriate for the problem.


Keith
--
Keith Davies "History is made by stupid people
(e-mail address removed) "Clever people wouldn't even try
(e-mail address removed) "If you want a place in the history books
http://www.kjdavies.org/ "Then do something dumb before you die."
-- The Arrogant Worms

 

[Me]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably experienced
C++ programmer produces per day. I reckon on a good day I can knock out
200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

The answer is...zero! A good programmer will reuse previous work and
avoid programming if at all possible.

Many years ago folks tried to measure productivity by number of lines of
bug-free code written, but the metric is pretty useless when you consider
that it's not all about writing a lot of code.

I'm more interested in the design methodology used: did the SE properly
analyze the task? did they research proper reuse of existing code/
systems? then, how simple and elegant was their solution?

 

[Ron Natalie]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

On a good day, I have a negative code output. I deal with managing
a million line legacy code project.

 

[Jerry Coffin]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

It's sort of a waste of time, but has a few uses as well. If you want to
get into it, there are quite a few books on the subject -- Googling for
"Barry Boehm" should give at least a reasonable start. Asking on a
software engineering newsgroup would probably yield a lot more pointers
as well.

 

[Puppet_Sock]

I delete 20 to 50 lines of code per day...

Heh heh. You likely have a negative bug rate then.
Socks

 

[Juha Nieminen]

Heh heh. You likely have a negative bug rate then.

As they say, "every program has at least one bug, and every program
can be reduced by at least one line; this means that all possible
programs can be reduced to one single line, which doesn't work".

 

[Jim Langston]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

42

 

[Phlip]

Heh heh. You likely have a negative bug rate then.

Bugs? No. The point of deleting lines is preventing future bugs.

 

[James Kanze]

Bugs? No. The point of deleting lines is preventing future bugs.

I think his point was that when you remove lines, you also
remove bugs. So you are producing a negative number of lines,
and a negative number of bugs.

Statistically, I'm not sure that's good: a negative over a
negative results in a positive, so your bugs per lines of code
ratio won't be all that good.

(FWIW: my record is doubtlessly the time when I replaced 2000
lines of code---all in main()!---with 180, in one 14 hour
session. That's -130 lines of code per hour. It's easy to look
good if your predecessor was really bad.)

 

[James Kanze]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

The number of lines of code a well organized team will produce
will depend on a lot of factors: the competence of the team
members, of course, but also the application domain, the
language, and so on---a team producing its 20th version of a
corporate pay program will produce a lot more lines than a team
writing a distributed OS in C++.

And the important figure isn't lines of code per programmer, but
for the team. A programmer well supported by people on the team
who perhaps don't write a single line of code will be far more
productive than a programmer who has no support. (How do you
account for time spent writing user documentation, for example?
Or negotiating the contract?)

In the end, I think you have it a bit backwards. The way lines
of code are used is to start by determining, empirically, how
many lines of code your *team* produces, for your particular
application domain, using your particular tool set, and with the
support functionality that you have available. You then also
determine roughly how many lines of code it takes to implement
various basic functionalities---again, for your team, in the
language the team uses, using the methodologies that you use.
Given that, you can usually make a pretty good estimate as to
how much effort it will take to implement a given set of
functionality in the future, which serves as the basis for
estimating a price and a delivery delay.

 

[Ian Collins]

In the end, I think you have it a bit backwards. The way lines
of code are used is to start by determining, empirically, how
many lines of code your *team* produces, for your particular
application domain, using your particular tool set, and with the
support functionality that you have available. You then also
determine roughly how many lines of code it takes to implement
various basic functionalities---again, for your team, in the
language the team uses, using the methodologies that you use.
Given that, you can usually make a pretty good estimate as to
how much effort it will take to implement a given set of
functionality in the future, which serves as the basis for
estimating a price and a delivery delay.

I'd argue that you can eliminate determining how many lines of code your
team produces and just measure how long it takes to implement the
functions, stories or whatever it is you implement.

Lines of code are completely irrelevant. I wouldn't have a clue how
many I or my last team do in a day.

 

[John Bode]

I know this is very much dependent on complexity etc but is there a
standard benchmark number of lines of code that a reasonably
experienced C++ programmer produces per day. I reckon on a good day I
can knock out 200 lines. Is that good? Bad?

Or is this benchmakr a bit of a waste of time?

I know this is a bit of topic but I am genuinely interested. And no I
am not a troll.

SLOC is the least meaningful metric for measuring anything. A
programmer is not judged by the volume of his output, but by the
quality of it -- is the code correct, complete, robust, maintainable,
etc.? Several people have mentioned that they spend a lot of time
time culling dead or deprecated code. Should that be counted as
negative productivity? I've written thousands of lines of code that
wound up being tossed because an external dependency changed. How
should that be measured?

It's not about pounding out massive amounts of code, it's about
solving the problem.