• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How much code per day

 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello, I have a question. How much code does a common java developer write a day??? I heard that the standard was 25 lines of code per day but that is also included in days in which there are meetings. For example if you have a meeting on monday to discuss design and you write no code you still must make up for your 25 lines on tuesday so now tuesday you must average about 50 lines. Is that true

thanks
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
25 lines sounds awfully little.
Some days I may write a thousand lines, the next day I throw half of it away and rewrite the same in a hundred lines. Those are realistic numbers btw.
Now how much have I created?
I've written 1100 lines in 2 days, but there's only 600 lines of code.

And other days again I write nothing at all, maybe because I'm updating documentation or working on testing or design.

KLOC figures are completely useless to measure programmer performance.
All they do is encourage code bloat and copy/paste programming.
If our efficiency were measured in KLOCs, why should I try to move common code to abstract base classes? My count would be much higher (and thus my measured efficiency) if I just copied and pasted all that code into every single class I create.
For my current project that would have added thousands of lines of code, quite a feat for a few times using Ctrl-C,Ctrl-V
Not to forget that refactoring can cause you problems as well. At one point I DID work for a project where KLOC figures were used to measure performance of the team.
For one release we did a major performance improvement and cleanup operation, cutting over 10000 lines of dead code and adding maybe a few hundred.
We were attacked for having a negative KLOC count, instead of praised for making the existing codebase higher quality and easier to maintain.
As a result of that debacle KLOCs were abandoned there and replace with function point analysis.
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I find this to be a very interesting question... so interest, in fact, that I asked it a few years ago here. :-p

You might want to take a look at that thread. In any case, I feel this question is more appropriate for the Process forum, so I'm moving it there.

--Mark
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Today, I must have written around -500 lines... (yes, that's a minus-sign)
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Today, I must have written around -500 lines... (yes, that's a minus-sign)


You're good!
 
Ranch Hand
Posts: 469
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Last month I have written about 40 files with average 200 lines of code per file. Some are .java code files (300 lines of code or more) and some are .jsp (30-150 lines, about half of wich is HTML)
I subtracted about 1/4 of the file length for comments and spaces.
So if I count HTML as code and I ignore that most of HTML files I re-use in some way, I write about 40*200/22 = 360 lines of code, but I also do database development and watch after servers 20-30% of work time, so if I did coding only, it would probably be 400-450 lines of code per day (7,5 hrs work day). Seems less to me now that I look at the number
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael Huber:

I heard that the standard was 25 lines of code per day but that is also included in days in which there are meetings. For example if you have a meeting on monday to discuss design and you write no code you still must make up for your 25 lines on tuesday so now tuesday you must average about 50 lines.

Not only that, but I think the lower numbers one hears about count only fully debugged lines of code that make it into the final product. If a subteam writes 60,000 lines of code but it all gets axed from the final product, none of it counts.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and what if it makes it into the product but the product never gets delivered (or gets delivered but never used?).
I've had that happen several times, once wrote a major (10K lines) piece of code for a very substantial database conversion (on which large pieces of code from others depend, totalling maybe 300K lines) only to have the customer cancel the project a day before delivery because they consider it too risky.
10 man-months of work down the drain (not counting time spent by analysts, testers, coffee machines, etc. etc.).
In fact, had something like that happen 3 times in one company, then once again in another at an even larger scale.
There it was 20 man-YEARS down the drain when corporate politics decided the project would be scrapped and another team started to effectively build the entire application again from scratch using different technology, different hardware, etc. etc. with different people (at that time the application had been life for a few months, millions worldwide spent on marketing campaigns, more hardware and application server licenses ordered to the cost of several million Euro and from one minute to the next (literally, the first thing anyone heard of the cancellation was when the project manager got a phonecall that his project was cancelled per immediate) we're told to stop working except to replace the website with a "service unavailable" page.
Was 3 months before they put us on other projects, that's 10 people (7 external consultants) sitting idle for 3 months after effectively working 18 months 10+ hours a day for nothing before that.

How do you count the code written there?
 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I didn't realise that some organisations measured performance by means of line counting, that's bizarre. Does whitespace count?

I don't think it's really possible to get meaningful figures out for line count. As has already been stated, often you will come to work and just replace a whole load of bloaty code you wrote 6 months ago with perhaps just a few lines. I feel much better about making things well designed in this way and making the code much more maintainable than I would do if I wrote 1000 lines a day. Fortunately where I work is pretty laid back and we have no official performance markers (most code is written for internal applications so clients are mostly internal), we just aim to make sure the final product does what it should in an efficient way.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As a metric, Lines of Code/day is one of the worst. Every study I've ever seen has stated that it can vary wildly.

I try to stay from places with LOC fixations, since I ultimately want tight, clean, reliable and efficient code. Which means that many days, I'll end up with fewer lines than I started with.

Come to think of it, LOC is measured on the results, not against all the inserting, moving, modifying and deleting, so it doesn't even accurately measure all the purely mechanical work done, much less what really counts - which is how much functionality has been added to the system over the course of the day.

And there are times where a day is too small a measurement interval. I've left work for the day many times saying, "I've got the transmission taken apart and the parts all over the floor; tomorrow I'm going to start putting it back together".

Software productivity is one of the hardest things in the world to measure. But that never stopped the bean counters.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ben Wood:
I didn't realise that some organisations measured performance by means of line counting, that's bizarre. Does whitespace count?


Only if you're programming in a certain language
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's a poor metric but can be somewhat useful in an organization with a heavily standardized way of producing software. From a organizational rather than a individual POV. The problem is that using LOC's as a positive measure of individual or team performance instantly introduces a strong incentive for the worst possible behavior. Your best people, who recognize that it's BS, will start looking to decamp. Others will simply inflate their code with well-known tricks.

One place I worked there was a guy who could outcode me two for one (in LOC's) every day. I had a bit of an inferiority complex until he quit and they gave me some of his code to maintain. Something of a nightmare until I refactored and learned that I could shrink the code anywhere from 50-75%, making it much easier to maintain, extend, and change the software. Note that this place Did Not use LOC's to measure anything (which is why I stayed). The group was run by a little redfaced Irish mammy-jamber who was one of the best managers I've ever worked for.

Consider using it as a reverse measure, but do it carefully. That is, for the same number of function points give a kudo to someone who did it in the least LOC's. The problem here is that you need as much complexity as you need to meet the requirements, not less. And you may be introducing an incentive to not meet the requirements this way...
 
Ben Wood
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Only if you're programming in a certain language



that's brilliant! Some people simply have too much spare time on their hands
 
Sania Marsh
Ranch Hand
Posts: 469
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's like in bioresearch, you cannot measure the amount of work done by counting dead rats per day.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rita Moore:
It's like in bioresearch, you cannot measure the amount of work done by counting dead rats per day.



I love it!!!

 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim Holloway:

As a metric, Lines of Code/day is one of the worst. Every study I've ever seen has stated that it can vary wildly.

I agree it's a bad standard for individual performance. On the other hand, I'm not fond of the "how many hours does he stay at work" standard, either - it encourages people to go to work even when they are too sick or too tired to do anything productive.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ben Wood:


that's brilliant! Some people simply have too much spare time on their hands



Lots of people have too much spare time on their hands:

http://www.99-bottles-of-beer.net/.
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
...of which one favorite waste of time is Beatnik.

http://www.cliff.biffle.org/esoterica/beatnik.html
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
Tim Holloway:

As a metric, Lines of Code/day is one of the worst. Every study I've ever seen has stated that it can vary wildly.

I agree it's a bad standard for individual performance. On the other hand, I'm not fond of the "how many hours does he stay at work" standard, either - it encourages people to go to work even when they are too sick or too tired to do anything productive.



Yah. I used for a place where the rule was "(s)he who leaves last wins!" The whole thing is a factory-worker mentality. In knowledge work, many times, the REAL productivity is the flash of inspiration that comes while taking a shower or before waking up in the morning.

I have no doubt that YMMV, but I determined a long time ago that MY most productive time was in the 8am to noon range (often implementing the "flash-in-the-shower" idea). I tried - when the job was appropriate - to interact with users and locate problems and possibilities for improvements in the afternoon. In the PHB world, of course, this is classified as "sitting around and BS-ing" - unless of course it's them doing it. But while admittedly a certain amount of bull gets shot, this is where I learned that over-analysis of a system is pointless, because the user has learned new ways to do things with the new software, and now needs new support features.

Anyway, my brain has usually died by about 2:30pm. The rest of the day I might as well be replaced by a cardboard cutout. I'm NOT paid by the hour, BTW.

Actually, a nap in the afternoon would give me a second productivity boost in the afternoon or evening, but that doesn't fit in with the mill-worker commuter paradigm for the workday. Nor am I willing to drive 35 minutes through road-rage traffic to go home and then drive 35 minutes to come back for a few more hours at work. So actually, I'm more productive as a teleworker.

Such is life in the USA. Bean Counters prefer DRD (Dead Rats/Day) and HBIP (Hours Body In Place) because they're so easy to measure, so the "productivity-minded" shops will go on using them as measurements.
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If u are a architect, you will not produce any code.
You will make others produce based on your silly ideas.
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:
If u are a architect, you will not produce any code.
You will make others produce based on your silly ideas.



that's actually an Anti-Pattern: http://c2.com/cgi/wiki?ArchitectsDontCode
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I did sense a healthy dose of sarcasm in Kishore's post
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Daniel Mayer:


that's actually an Anti-Pattern: http://c2.com/cgi/wiki?ArchitectsDontCode



I am not saying all architects. I am sure of some(because of first hand experience).

Personally, I can not survive without coding(even if that does not have to do with work related stuff).
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think many people here ar taking an extreme view. The qustion is not "does SLOC production act as a good metric for performance?" but rather "(how) can/does SLOC production relate to overall productivity?"

Yes, it's a bad organization who says, she who writes the most code wins.

But good organizations can use SLOC, along iwth other metrics to measure performance. Given 10000 developers, it'll bet most those in the top decile are more productive than most those is the lowst decile. Notice that I said, most in the best and worst groups. I suspect many of you would agree with so strong a statement. If you do, then we agree that SLOC does have some correlation to performance. The question than becomes how much of a correlation and under what circumstances, e.g. we expect an architct might product less code because of his other responsibilities, or that someone working on a very complex algorithm would also yield less code than the average developer.


What other sources of mesurement do companies use? Revenue generation, savings, output (documents, widgets, leads, test scores), recycling usage, tons of material processed, miles flown, earnings per share, etc. No one ever claims any one of these to be the best metric. Good traders or salesmen (measured in revenue produced) may have bad quarters. A good recycling program may not recycle the most material, but may do so at a lower cost. The teachers who produce the highest test scores among their students are not necessarily the best at educating overall. Very rarely is a single number going to sum up everything. But we need some type of measurement. What is important is to understand what is being measured and how it relates to the actual work. In this sense, I think SLOC does have value.

--Mark
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mark Herschberg:

The qustion is not "does SLOC production act as a good metric for performance?" but rather "(how) can/does SLOC production relate to overall productivity?" ...

Yes, it's a bad organization who says, she who writes the most code wins.

But good organizations can use SLOC, along iwth other metrics to measure performance.


Hm, you were making a distinction between measuring performance and relating to productivity, then you got back to measuring performance.

I'm not convinced that a good organization can use SLOC to measure individual performance, because of people issues - it's at least a little unfair, and it will be perceived to be much more unfair, particularly because it's exploitable and will be exploited.

On the other hand, I think an organization might be able to use it to measure organizational productivity. This might, for example, help the organization make tradeoffs between, say, hiring more programmers versus providing better working conditions - quieter cubes, bigger monitors, whatever.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
Given 10000 developers, it'll bet most those in the top decile are more productive than most those is the lowst decile.



I'd actually bet the other way around. Whenever I say bad code - code that is contains lots of bugs and is a pain to modify, I see code that can be significantly reduced in size by applying some standard techniques. I see code that does the same thing in dozens of different ways (each with their own bugs, of course) and even duplicating basic functionality that's already provided by the JDK.

In my not so humble opinion, the key to being productive is *not* writing more code in the same time, but using enough time to think about ways to have to write less code.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone work in an organization that measures "SLOC Deltas?"

I'll define SLOC Delta as ABS(# of lines added - # of lines deleted). If you've got a high SLOC Delta metric, that means you're either writing, or deleting, a lot of code, so it's a measure of impact. Maybe

ABS(# of lines added - # of lines deleted) + (# of lines changed)

You could calculate this automatically from CVS check-in messages.

I'm just riffing, but what Ilja wrote above is a recurring theme for me -- I recently wrote a mini-essay about this here.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I often tell my team that deleting code is my favorite part of programming. It usually means I've found a better algorithm or a chance for reuse. It's often possible because too many people never read what they write and even the most casual reader will find opportunities to delete cruft.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I often tell my team that deleting code is my favorite part of programming. It usually means I've found a better algorithm or a chance for reuse. It's often possible because too many people never read what they write and even the most casual reader will find opportunities to delete cruft.



Agreed. That's only part of why I dislike LOC based performance metrics, though.

Software development is to a big part a *social* activity, and any purely technical metric is therefore highly inappropriate as a *performance* metric, imnsho.
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja Preuss:

I'd actually bet the other way around. Whenever I say bad code - code that is contains lots of bugs and is a pain to modify, I see code that can be significantly reduced in size by applying some standard techniques.

However, you don't know how long that code took to write.

Studies that have looked at both quantity measures and quality measures find that they are positively correlated. In other words, the same programmers who write more code also tend to write higher quality code.

That bad code that can be improved by removing 80% of it was probably written very slowly and laboriously.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
However, you don't know how long that code took to write.



That's true...


Studies that have looked at both quantity measures and quality measures find that they are positively correlated. In other words, the same programmers who write more code also tend to write higher quality code.

That bad code that can be improved by removing 80% of it was probably written very slowly and laboriously.



That's interesting. I'd suspect that it depends on the time period - rape and paste programming will produce many LOC in the first days, but after a short time you get bogged in lengthy debugging sessions...?

Interesting thought.
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja Preuss:

That's interesting. I'd suspect that it depends on the time period - rape and paste programming will produce many LOC in the first days, but after a short time you get bogged in lengthy debugging sessions...?

I was also surprised about the direction of the correlation when I first found out about it, and what you write is my theory too. For that reason, I think lines of code measures need to have a baseline of a complete project, from inception to shipping, including all debugging. Plus, if it's measured on an individual basis, you have to make sure that the person who wrote each bug has to fix it, which isn't generally true on most multiperson projects.
 
reply
    Bookmark Topic Watch Topic
  • New Topic