File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes How much code per day Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "How much code per day" Watch "How much code per day" New topic
Author

How much code per day

Michael Huber
Ranch Hand

Joined: Aug 20, 2004
Posts: 43
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
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
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.


42
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Today, I must have written around -500 lines... (yes, that's a minus-sign)


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
Today, I must have written around -500 lines... (yes, that's a minus-sign)

You're good!


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Sania Marsh
Ranch Hand

Joined: Jul 12, 2004
Posts: 469
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
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
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

Joined: Oct 12, 2000
Posts: 5093
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?
Ben Wood
Ranch Hand

Joined: Aug 14, 2001
Posts: 342
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.


SCJP 1.4, www.gsi3d.org.uk
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15951
    
  19

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
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

Joined: Aug 14, 2001
Posts: 342
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

Joined: Jul 12, 2004
Posts: 469
It's like in bioresearch, you cannot measure the amount of work done by counting dead rats per day.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15951
    
  19

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
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
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.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
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/.


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
...of which one favorite waste of time is Beatnik.

http://www.cliff.biffle.org/esoterica/beatnik.html
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15951
    
  19

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.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
If u are a architect, you will not produce any code.
You will make others produce based on your silly ideas.


Kishore
SCJP, blog
Daniel Mayer
Ranch Hand

Joined: Sep 09, 2004
Posts: 103
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
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Yes, I did sense a healthy dose of sarcasm in Kishore's post
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
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
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How much code per day
 
Similar Threads
I wanted to aks this: How much code You can write without testing?
Initial Capacity of Collections
Create an Action
also need help this code
Project Questions