How many lines of debugged code do you produce in a day's work?

Question

How many lines of debugged code do you produce in a day's work and what language would that be?

I know some languages are a little more difficult to work with but on average, how many?

Answer 1

On a good day 1000 lines of bug-free code.

On a bad day I write no code at all.

In average I would expect that I write around 200 lines of bug-free code a day.

All this in good old C.

Answer 2

It varies a lot. The closest approximation I can make for lines of code written in a fully productive day would be "several hundred", including lines of both test code and production code.

Answer 3

It's not a matter of quantity :) but of quality.

Sometimes there are days where I struggle with one problem and the solution may be 10 lines of Code, on other days it can be thousands of lines with typing stupid code (DB-Mapping as example). (C#)

Answer 4

Didn't your mom tell you not to measure productivity in lines of code?

Answer 5

I don't have an exact count, but on my best days it's a negative number.

Answer 6

Today I'm at about -250 so far :)

Answer 7

Sometimes I spend all day removing lines of code from the project during refactoring. This kind of work is important, but difficult to guage in terms of progress metrics (negative lines of code?).

But about 200-300 lines per hour on a good day. And I can't keep that up for 8-10 hours, so it ends up anywhere between 800-1500 lines of (apparently) bug-free code, again on a good day where I'm writing new code and not refactoring old code or fixing old bugs. This is in Perl.

Answer 8

The problem coming up with a number is "how do you count 'lines of debugged code'?"

If I writing 1000 lines yesterday which didn't work, and today fixed it by changing one line, did I write 999 lines yesterday and one today? Zero yesterday & 1000 today? And if next week another problem is found which requires another one line change, did it take me 10 days to write those 1000 lines. What if I bug is found three years from now? Does my average drop to 1 line a day over three years?

Answer 9

It really depends on your language, and what it is you're coding.

Some languages are more verbose than others, and require a lot of code to get anything done - so even a small functional change will result in a sizeable chunk of code. Some coding practices require regular refactoring, which can create a lot of extra code before you even start adding new stuff..

Also, if you're starting a new project then you can probably churn out over a thousand lines without too much trouble, and towards the end it's possible that a single line can take you all day.

As has been mentioned elsewhere, once you get into the debugging/optimising phase, you'll often find yourself removing more code than you add, so measuring productivity in lines of code is both misleading, and leads to bad development practices (you really don't want to give developers a reason to make code more complicated than it needs to be!).

However, lines of code is a reasonable (although far from perfect) measurement of the complexity of a codebase. Simply because more code = more stuff to read and understand. But don't fall into the trap of using it to measure productivity.

Answer 10

@Gary In a comment you mention

People moving into a software development career need a rough estimate of what industry demands

I have no idea and it does not matter to me how many lines of code each programmer produces. When I am interviewing people the number of lines of code they can produce is the last thing I demand.

If the company is demanding X lines of code per day you are probably better off not working there.

As others have mentionned, on my good days I spend most of the day un-producing lines of code.

Edit:
Just in case it is not obvious why this should not matter, remember that most good programming practices are about writing less lines of code (from the simplest advice of writing a function instead of repeating the same code over and over, to using libraries that abstract away code you don't have to write ...)

Answer 11

This is a very interesting question. But not from target of productivity else from project grow. A typical developer will write approx. 200 loc. This are in the year approx. 50,000 loc. If I have for example 20 developers in the team then the project will grow 1,000,000 loc per year. If it is a continuous project development (like the most projects) then this will occur every years.

And now are the problem. If after a year a new version of the software is coming then it is not better. It has only more features. I think this is a large problem of many projects.

Answer 12

Ignoring the fact that LOC is not a good measurement. But wouldn't it be wiser to count the amount of (unit)tested code?

Answer 13

A Have some numbers from the past: IBM checkout scanner 1551 lines/man year Lotus 1-2-3 version 3 1520 lines/man year Space Shuttle 1163 lines/man year Lincoln'89 2327 lines/man year Citibsnk Teller lines/man year

Source ISA Transactions 1991 page 84

Greetings,

Willem Hazenberg

Answer 14

I just counted; I've written an average of a bit over 40 lines of perl per day over the past year.

There are relatively few days when I actually write code (maybe one day a week); most of my time is spent in meetings, hashing out user requirements, investigating and importing new data sources, reverse-engineering the data formats of those data sources, changing parameters within the code to new user specs, re-writing or deleting code because the users changed their minds, debugging the original legacy code, debugging errors that happen every time we install a new operating system or a new version of the database interface software, debugging errors caused by changes to other applications that my application interacts with, profiling and tuning the code, testing the code, packing up distributions, writing documentation, corresponding with users, etc., etc. Also: lolcats.