How many lines of code per day should a good programmer produce?
Angus
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.
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Puppet_Sock
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
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
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
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.
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...
--
Phlip
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
LordO...@googlemail.com
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
keith....@kjdavies.org "Clever people wouldn't even try
keith....@gmail.com "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
On a good day, I have a negative code output. I deal with managing
a million line legacy code project.
Jerry Coffin
angus...@gmail.com says...
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.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Puppet_Sock
Heh heh. You likely have a negative bug rate then.
Socks
Juha Nieminen
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
Phlip
>> I delete 20 to 50 lines of code per day...
>
> Heh heh. You likely have a negative bug rate then.
Bugs? No. The point of deleting lines is preventing future bugs.
--
Phlip
James Kanze
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 (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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.
>
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.
--
Ian Collins.
John Bode
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.
James Kanze
> James Kanze wrote:
> > 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.
It comes out to the same thing in the end. It's just that many
people find it easier to associate a count of lines of code to
some functionality, than to associate time directly. The real
question is: what is a single "story" or function point (as
opposed to two or more)? Even in a given domain, the size and
complexity of a function point will vary some. Experienced
designers generally seem to have some feel about how many lines
of code it takes to implement any given function point, and you
go from there. It's not an absolute, of course. It's just
something that has been found to work in a lot of places.
(Other places do use function points.)
red floyd
> exec in command line?
>
Depends. During requirements analysis and design, none. During
coding, it depends on how well you designed.
Jorgen Grahn
don't do that -- most people with a real news server have no idea what
you're talking about (especially since you don't quote anything and
don't write complete sentences).
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodb...@gmail.com
>
> 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.
>
and there were a couple of complaints because the
code was thousands of lines long. Anyway, there are
4,435 lines in the archive here --
http://webEbenezer.net/build_integration.html .
991 of that is from a compression library that someone
else wrote and I've never had a problem with. 84 lines
are in a Readme file. That leaves 3,360 lines of code.
I agree with the comments about reworking code to make
it more concise. With G-d's help I've been able to
put a lot of time into that, and now that the code is
getting better, I find it's getting harder to ignore
some Microsoft warts in the code...
#ifdef CMW_WINDOWS
WSADATA wsa;
int result = WSAStartup(MAKEWORD(2, 2), &wsa);
if (result != 0) {
throw failure("WSAStartup error is ") << result;
}
#endif
#if defined(CMW_WINDOWS)
#define poll WSAPoll
#endif
In another thread I mentioned how not being able to
use non-static data member initialization in class
declarations is another wart because of Microsoft.
I bring this up in the hope that someone will say
support for this has arrived or will arrive shortly.
About 5% of two of my programs amount to these warts.
If someone is interested in reviewing the code for
compensation, you would have to be willing to accept
about 80% of it in terms of an investment in my company.
We would have to agree on how much each suggestion is
worth. I can see that ranging from $20 to hundreds of
dollars. Keep in mind, I'm sometimes stubborn and
won't take a suggestion for years until it makes sense
to me that I should. I would do my best to let you
know of my change of mind in such cases. And keep in
mind that I'm already aware of some good suggestions.
For example, the library part of the code, in particular,
should be more consistent in terms of naming.
There's info about investing here --
http://webEbenezer.net/about.html .
And I'll add that you're not waiting for me to be
rewarded in terms of the list of investments. I've
invested lots of money and time in the company, but
I'm not on that list.
Brian
Ebenezer Enterprises
http://webEbenezer.net
Pavel
produced.
-Pavel
Andy Champ
The old number always used to be 4 lines a day, designed, coded and
fully tested.
Andy
Jorgen Grahn
> On 09/09/2012 17:37, Pavel wrote:
>> IMHO on a good day a good programmer should remove more lines of code
>> than s/he produced.
>
http://en.wikipedia.org/wiki/Augean_stables
Öö Tiib
However if it is work on new feature then production code might change -100 to +100 but you always write like 100 lines of unit tests as well then so that makes 0 to +200 lines. But that is when you really write software. THese days it is unusual.
All in all the whole team effort (including designing,documenting,testing,reviewing,deploying) is something like a non-empty line of code per man-hour.
Pavel Volkovskiy
> 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.
David Brown
character or two.
I have also had a case where I found the bug in a couple of hours, and
the fix was only two or three lines - but it took several days to
re-organise the program to get enough space for the fix (this was in
assembly rather than C++, and on a very resource-limited
microcontroller). But it certainly doesn't amount to many lines of code
per day!
Andrew Cooper
23765, although its hardly very interesting on its own)
The point is - you cannot, nor should not judge "how good a programmer
is" by lines of code.
Jorgen Grahn
> I have also had a case where I found the bug in a couple of hours, and
> the fix was only two or three lines - but it took several days to
> re-organise the program to get enough space for the fix
the paperwork, so to speak.
But the idea of lines/person/day is bogus, of course.
Everywhere
> I
> On Tuesday, October 2, 2007 8:29:40 PM UTC+2, Angus wrote:
>> 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.
>
> he should then refactor to 50 to make it maintainable (or
> just for the heck of it).
>
> Or perhaps, he should start with 50, and then use his
> favourite editor to cut and paste it up to 10000. He
> will at least pull the wool over some managers eyes.
>
> But... for those kind of metrics, the better question is
> rather - "How many lines shall I write for you today, sir?"
>
> Kind regards,
>
> Werner
That would depend on your intended life cycle and optimization needs.
coa0...@sheffield.ac.uk
> Angus wrote: > 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 isnot. > 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-- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask
There is no need to be so pedantic Victor!
er...@indichocolate.com
"I didn't have enough time to write you a short letter, so I had to write you a long letter instead."