|
How many LOC per day?
I know it all depends, etc, but I'm still curious about what's considered low/normal/high productivity. Even if these numbers are only meaningful for certain languge(s).
I usually crank out about 200-300 LOC of debugged Perl code a day when programming trivial things. I think it's higher than average, but I'm sure there're many people who're more productive.
What are your numbers? What's low/normal/high in general?
Egor
Thursday, May 6, 2004
I can write about 3000 thousands line of comments per day
FanBoy
Thursday, May 6, 2004
3 million lines of comments a day? That's pretty impressive!
John Topley (www.johntopley.com)
Thursday, May 6, 2004
A lot of it is like asking why the Air Force puts the cost of a hammer at $300.
Do you factor into that 200-300 lines the time spent discussing the request? Documenting it? Delivering and training? Supporting clueless users who don't read the documentation? Sitting through requirements reviews, design reviews, test readiness reviews, etc, etc, etc.
When you apply all the related costs, a hammer really is $300, and you're writing 50 LOC per day.
Tom H
Thursday, May 6, 2004
The higher your average LOC per day, the more likely you are what is oft considered a "code monkey".
Dennis Forbes
Thursday, May 6, 2004
Tom, you're rising valid points, but I'm interested in the kind of productivity that is actually measurable. I don't see how else you could gauge it other than LOC/day.
Egor
Thursday, May 6, 2004
Dennis, had you read carefully, you'd have noticed that I said "on trivial things". I mean things that you know how to code right away, because you've done similar stuff before. That is, I'm talking "code monkey" situation by definition, otherwise the productivity would be unmeasurable.
Egor
Thursday, May 6, 2004
>LOC/day.
This is a useless meassurement. LOC/day is much higher when you write the code for the first time. When you get into maintenance programming your aim should actually be to remove lines from the codebase.
That will give you a negative LOC/day-count, but you did a good job anyway.
This removing of lines from mature code is always my highest priority. Find better algorithms of doing what you need doing. Also consider that most of the time you need to make changes that improves performance, and that has very little to do with how many LOC you produce. You need to find another meassurement to gauge productivity.
Patrik
Thursday, May 6, 2004
Patric, I don't see how the points you're bringing up make LOC/day a useless measurement. Refactoring is fine, but it's exactly "write the code for the first time" what I'm trying to discuss.
Egor
Thursday, May 6, 2004
Egor,
A good manager can always tell which programmers are productive and which ones aren't. LOC is hardly a measure of such things. Examples:
Scenario 1:
I've seen hard workers that get things done by putting the time in. They would come in, crank out tons of code, and put in extra time and code past that which was required of them. These people are productive, but from a brute force means.
Conclusion: Productive
Scenario 2:
I've seen workers that moan and gripe about things, crank out a lot of smart code when push comes to shove, but ultimately they aren't productive because their code is so sloppy and ill-formed that its not maintainable, debugable, and thus unusable.
Conclusion: Not Productive
Scenario 3:
I've seen smart workers that are lazy, but they get their work done, and get it done fast and well. There is just down time between getting things done. Just as much work is accomplished as in the previous productive example, however it is accomplished in far less time. The code is ultimately cleaner, shorter, and easier to maintain.
Conclusion: Productive
Scenario 4:
I've seen smart workers that are lazy and when push comes to shove they crank out unmaintainable code. The code produced is often not useful in the long term, and the person doesn't produce much non-useful code.
Conclusion: Unproductive
Scenario 5:
I've also seen not so smart workers that sit around working hard, cranking out code all day long, that ultimately is buggy, long, and mostly useless. They put in long hours really giving it all their effort, but lack of talent and skill prevent them from doing anything useful.
Conclusion: Unproductive
Of these four scenarios, I would stack rank them as a programmer in the following order:
3 1 2 5 4
Management would stack rank them in the following order, traditionally based on lines of code, and effort:
1 5 3 2 4
The ultimate coder would be one that works 10 hours a day producing absolutely brilliant maintainable succint code. I'm sure that they are out there, but I haven't yet found one. If such a phantom coder existed, he would obviously be placed at the top of both stacks.
Either way the point is, if you are familiar with your developers and the code they produce, then the (in my opinion) proper ranking is the first set. If you base your decisions of of level of effort and metrics, you'll wind up with the second stack. It's a hard line for me to pick a "best" between Scenario 1 and Scenario 3. Personally I think I'd rather have someone that once a week produce a chunk of brilliant code then someone that crunched away tirelessly for the same week to achieve the same result. I'd think that Scenario 1 will eventually burn out.
Elephant
Thursday, May 6, 2004
"Tom, you're rising valid points, but I'm interested in the kind of productivity that is actually measurable. I don't see how else you could gauge it other than LOC/day."
LOC is an absolutely useless comparative metric unless you're comparing two people with the same role, in the same team, in the same organization, performing the same sort of development, with the same tools and same information, as well as a highly similar coding style (i.e. both abstract to the same degree, avoid redundant code, etc). It most certainly has no value comparing across the industry where one person might be doing monkey work document processing basically spitting out the same code they spit out day after day because they haven't noticed similarities and, and another person is creating a generalized module for highly complex financial transactions.
Dennis Forbes
Thursday, May 6, 2004
Egor,
Ok then...my LOC varies radically even when producing new code. Say I write 200 lines of Delphi code one day and feel good about myself. Next day I find something that can be done better, and I remove 100 lines of code, and add 5.
Then PHB comes along and sees my productivity dip and wonders why I am such a slacker.
Count in meetings, workshops, specing and debugging and you will average about 10 LOC/day over a long period of time.
Useless. What should count is the time of the entire project, and that varies radically, depending not only on the LOC/day ratio of your coders, but the quality of your entire team.
Thus, it is a pretty useless meassurement.
Patrik
Thursday, May 6, 2004
I just wrote about a 500 lines of code that in the end don't get what was needed done, useless
The Artist Formerly Known as Prince
Thursday, May 6, 2004
"I don't see how else you could gauge it other than LOC/day"
There are other more useful metrics, like function or feature points, e.g. how many functional dialog box fields and buttons, how many algorithms, and how many different data elements that can be saved or loaded did you average each day.
Ron
Thursday, May 6, 2004
I'm pretty sure Munch generally painted more strokes/day than Picasso, so obviously Munch is a much better painter.
Of course, Stephen King is a much better writer than Hemingway, since he types more words/day.
Philo
Philo
Thursday, May 6, 2004
Uh, when Hemingway was alive, that is. Not currently.
Philo
Philo
Thursday, May 6, 2004
No i'm pretty sure Stephen King still types more words than Hemingway. If anything, it's given him even more of an edge.
Andrew Cherry
Thursday, May 6, 2004
Elephant,
Yours is an insightfully accurate explication of programmer productivity and ranking of programmers by productivity. I would like to think I'm a 1 (not that I wouldn't like to be a 3, but I know I got more brute force than natural talent). I'm afraid the truth is I fluctuate between 5, 1 and the occasional burst of 3 style output. Alwell, at least management thinks I'm money (for the 5/1 periods).
MacSqueeb
Thursday, May 6, 2004
The only correlation between productivity and LOCs is that coders that value LOCs are less productive.
Jan Derk
Thursday, May 6, 2004
If anything, this thread provides lazy programmers with a lot of good excuses.
Egor
Thursday, May 6, 2004
I don't think so. The point of my previous post was to point out that if you're not a hard worker, you'd better be damn good. And even if you are damn good, and not a hard worker, management typically (although I think incorrectly) picks the hard workers over the best workers. Now this is a blanket generalization that in no way applies to all companies.
If you mean that the thread is providing a diversion for us lazy workers, then you may generally be correct. I would guess though that much posting is done in down time between projects and tasks.
Elephant
Thursday, May 6, 2004
As an aside. . .
I personally found JOS, Fog Creek, and the JOS Forum roughly about a year ago. Management decided that they were going to start using LOC as a metric. I immediately went to searching the web for evidence that this idea was as bad as I knew it to be.
That's when I found an article that Joel wrote on the topic.
Find it kinda eerie that a year later, things have come full circle.
Best of luck in your line counting endeavors!
Elephant
Thursday, May 6, 2004
"If anything, this thread provides lazy programmers with a lot of good excuses."
Whatever Egor.
It is obvious that you approach programming as if it were stenography, proudly boasting that you're the fastest typer in the class. Prepare yourself for a lifetime of trivial monkey work...well, at least a year or two of trivial monkey work until your position is outsourced to India.
.
Thursday, May 6, 2004
"If anything, this thread provides lazy programmers with a lot of good excuses. "
It also provides insight to the mind of a person who still thinks LOC is a useful metric. You've been given several good reasons why LOC is a dangerous metric and you've completely ignored them and decided to mock the people who bothered to reply.
Mark Hoffman
Thursday, May 6, 2004
The key problem with LOC is it means nothing. Nothing. The goal of software is to *SHIP IT*. I can write a bazillion lines of bug infested code that doesn't meet requirements and I'm still no closer to shipping than when I started.
Let that sink in...It's important.
This is why smart companies evaluate performance in a way that is measured against the goal of shipping software.
Far too many business-challenged developers view their productivity in how many lines of beautifully crafted code they can write. They lack the basic business knowledege that their goal is to ship software, not build cruft.
Loci
Thursday, May 6, 2004
I'm amazed of how people in this thread are still arguing with the point no one is making. Did I claim somewhere that LOC is inherently useful and programmer's output needs to be judged based on it?
I'm just curious as to how much in terms of LOC daily people tend to write in what languge, working on trivial tasks. Nothing more, nothing less.
Egor
Thursday, May 6, 2004
Egor, you are missing the point. LOC is a useless, irrelevent statistic, even for "trivial" things
DJ
Thursday, May 6, 2004
In our product, which has to run on extremely constrained
platforms - our smallest has 7K of available RAM, 1.5K
of stack, and 64K of code space - a fat linecount would
be death. We do a fair bit of refactoring, and since we
have a "dynamic service" approach, most of the actual
code isn't used in a particular deployment, but our bias
naturally favors tight, carefully written implementations,
as opposed to brute-force type-fast-and-refactor-later
approaches.
x
Thursday, May 6, 2004
With an excellent monkey-work task raring to go, I top out at about 1200 lines of code in a day. That's with a VB-like language named dBase.
1/4 Ain't Bad
Thursday, May 6, 2004
Okay Egor, I'll answer your question:
VB6: between 1 and 150 LOC/day
C# (not counting comments): between 1 and 200 LOC/day
ASP.Net (including HTML): between 1 and 400 LOC/day
T-SQL: between 1 and 250 LOC/day
Does that help?
Philo
Philo
Thursday, May 6, 2004
Over a year, I average out about 27 LOC/day.
I am much more productive in terms of creating bug-free, functional software, than anyone I know of.
Tom Witherspoon
Thursday, May 6, 2004
Let's see, I can type roughly 40 words per minute accurately when I get in the groove. At about 5 characters per word average, plus spaces, that's roughly 240 characters per minute. In a C++ type language I am going to use the totaly arbitrary line length number of 25 characters per line. So, I can average roughly 9.6 lines per minute. In an eight hour day there are 480 minutes, so I guess in a day, I can max out at 4608 lines of code per day.
Let's review:
40 words/minute x
5 characters/word = 240 characters/minute
240 characters/minute ÷
25 characters/line = 9.6 lines/minute
9.6 lines/minute x
60 minutes/hour x
8 hours/day = 4608 lines/day
So someone print me out a couple hundred thousand lines of code that I can type in so I can be really productive!
Elephant
Thursday, May 6, 2004
Igor, you started - at the very top of your post - by commenting that you wonder about productivity.
You then ask about lines of code, and again mention productivity, explicitly linking "lines of code produced" to productivity.
It sure sounds to me as if you are making a value judgement about a programmer's (excuse me - software developer - (excuse me - software _engineer_)) productivity by the number of lines of code they produce on a daily basis.
As you should have learned by now from the other posts here, you are asking a nonsensical question. "Lines of code produced per day" has nothing to do with a developer's productivity. Whether or not the developer meets deadlines for shipping quality product is a better metric.
Remember - we are thinkers here. We generally don't do the same thing over and over again. There will be days that I don't write any code at all, because I'm writing specs or whiteboarding. There are days I crank out many, many screens in a prototype - generating hundreds of thousands of lines of code buried deep in the Delphi IDE. There are other days where I'll supervise people. There are still other days where I'll crank out several hundred lines of code. All are productive.
To judge a thinker's productivity by a mechanical metric makes no sense.
Karl Perry
Thursday, May 6, 2004
For me, I've had times when I'm cranking out the code,
closeted in my office, fingers a-blur across the keyboard
for weeks on end.
Other times, I may go several weeks without writing
a single line of code. I'm recruiting people, helping to
write/review marketing documents, being the "techie in
residence" in our booth at trade shows, etc. Arguably,
these tasks are at least as important to my company as the
code I write. But they don't add to the "LOC"...
x
Thursday, May 6, 2004
egor, i'm glad your enthusiastic, but you need a little more experience. There have been days where i haven't written any LOC, but they've been highly productive. What is my average LOC per day? I dunno. some days I write 100....other days I write 1000, course, some of that is copying and pasting....and sometimes I write even more...but then it doesn't always work right...so I have to spend the next day fixing it.... Do you understand? It has nothing to do with being lazy. If you want to prove how fast you are, tell us how fast you've finished projects: I was one of 4 guys who worked on a J2ee app that after six months we had about 200,000+ LOC. So that averages out to about 400 a day. ::shrug:: Still doesn't mean a thing.
vince
Thursday, May 6, 2004
The Wizard I use generate 8000 LOC in a fraction of a sec, does that count ?
FanBoy
Thursday, May 6, 2004
Whenever the boss comes around and I need to look busy, I just start typing a copy of whatever's higher up on the screen, so it looks like I'm churning out tons more LOC.
Does that count?
Slacker Bob
Thursday, May 6, 2004
LOC is mainly a measure of cost and effort, not of productivity. A million-LOC program almost certainly took more effort to build, and will take more effort and cost to maintain than a 100K LOC program. But as long as the 100K LOC program can do everything the million-LOC one does, the 100K LOC programmers would be the more productive group even if they coded 1/3 the LOC per day.
T. Norman
Thursday, May 6, 2004
Norman, I'm assuming you don't write million-LOC program to do the job 100K-LOC one can do. Neither do I, or, I believe, other posters, so I don't understand why this point gets brought up over and over again.
When asking this question I was thinking professionals with appropriate degree and several years of experience, not self-taught VB/PHP people coding in "stream of conscience" pattern. Sorry if I haven't made it clear enought.
In my experience, trivial code written by qualified professionals tends to be very similar and roughly of the same volume. But the time it takes them to crank that "same" code out can be quite different (much due to the time they spend debugging).
In much-acclaimed "Fact and fallacies of software enginering" Robert Glass urges you to estimate project volume in LOC. My estimation accuracy improved since I started doing it, so for me LOC has been anything but a useless metric.
Egor
Friday, May 7, 2004
"project volume" had to be "schedule", sorry.
Egor
Friday, May 7, 2004
I just tripled my productivity by using minimal-character-length variables!
a
Friday, May 7, 2004
Egor, LOC is a function of the size of the existing codebase (complexity), not a straight linear measurement. It takes far longer to put in and debug 100 LOC in a convoluted, complicated system than to do the first 100 LOC in a new app.
Or if that's what you meant by "trivial app", realize that not everyone here works on trivial apps, so answers to your question are meaningless.
Ron
Friday, May 7, 2004
43
.NET Developer
Friday, May 7, 2004
They're changing the Oscars next year. Top writer award goes to the guy whose script was longest. Top actor award to the tallest actor.
Steven
Saturday, May 8, 2004
Actually, there's a good chance that the Oscars might go to better films and actors if they made that change...
Chris Nahr
Sunday, May 9, 2004
 Recent Topics
Fog Creek Home
|
