The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Lines of Code per time

At what rate are you writing code?  What got me thinking about this was an article linked from another thread said they were writing 40 lines of code per day. 

I think the variables that go into this are the programming language you are working in, how buggy the code is when you are done and what amount of time.  I also suspect that the difficulty of the domain space, and the amount of knowledge in that domain space the developer has would also be big factors in determining the speed at which they can code something (and debug it).  Further, the experience the developer has with the code already in that project probably affects their speed. 

So, how fast are you coding?  Try to mention the above variables and suggest better/more variables that should be considered.  I am not really trying to be scientific here, and I am not arguing that lines of code is the best measuring stick of productivity (incidentally, I don't think it is).  I am just trying to get some idea of what is being produced out there and in what languages.

Personally, I have good days and I have really bad days.  Really bad days include distractions at the office, unclear or misunderstood requirements or having to do a demo of the program.  Good days include knowing the problem space, knowing the code to be implemented and generally making a new function or form. 

I work primarily in C# (some SQL) and a good day can be anywhere from 500-2000 lines of code (I am including Visual Studio .NET generated form code, which often bloats this number).  Often this code is found to have minor defects, mostly things that it should do, but I just didn't implement (like:  tab order or things being off a pixel, or intra-control interactions). 

Using code generators that I have written myself, it is entirely possible for me to write 12K lines of database plumbing code in a single day (I did this once for a side project).  Data base code is a very clearly defined problem space that has no user interaction.  I feel like that makes data base plumbing code straightforward, so this isn't that big of a feat, but still it keeps me from having to type so much.
Joshua Volz Send private email
Monday, January 09, 2006
a) Don't count lines of code, count function points
b) Don't worry about it.

Consider both points above together - your coworker codes 25 function points in one day, but they're all simple validations (if text box a is not a date, throw an error...)

In the same day, you stared at the screen for six hours, whiteboarded a lot, then rewrote one line and deleted fifteen other lines, making a major part of the data processing engine faster by two orders of magnitude.

So he wrote 650 lines and 25 function points, you wrote *negative* fourteen lines of code and no new function points.

Who's "better" ?

Philo Send private email
Monday, January 09, 2006
Interesting topic to consider, here are two variables that affect the number of lines of code one cranks out in a period of time:

1) availability of API libraries or other code base (components, reusable code etc)
2) the coding style of the person and the experience level. Sometimes using complex programming constructs or data structures might save you hundreds of lines of code especially in a large project.

In my current job I use mostly perl and C++. do not use code generators and try to reuse as much of available code as possible. On the best of my days I crank out about 1000 lines of perl or C++ code using my favorite editor (VI). On the worst of days its less than 200 lines of code. There are also days when I don't code at all, like when I am in the design or testing cycle for the application.
Jeff Bloom Send private email
Monday, January 09, 2006

I agree with your analysis.  I am not, in any way, saying that lines of code is a good measure of the "excellence" of programmers.  Nor am I saying that it is necessarily a good metric for measuring productivity.  As you point out, you can be very productive without producing very many lines of code.  I feel that my above discussion takes into account the point you bring up, in so much as the lines of code produced is going to be heavily weighted on external factors.  In this example, the factor is the complexity of the code, and the goal of coding.  In your example, -14 lines of code is an excellent rate because the external factors, mostly the goal of the coding, put that rate into context. 

As to your "Don't worry about it" point: I think we should be interested in exploring deeper measures of productivity.  Analysis of how we measure our productivity will lead to new ideas on how to measure it, and possibly to new ideas on how to improve productivity overall.
Joshua Volz Send private email
Monday, January 09, 2006
A few people have independently observed the 1 line/minute rate for Common Lisp. Perhaps this rate is independent of whether it's boring repetitive code or whatnot, as macros allow one to abstract things of this nature out... But I dunno.
Tayssir John Gabbour Send private email
Monday, January 09, 2006
Well, functions and macros.
Tayssir John Gabbour Send private email
Monday, January 09, 2006

I think that the language you are writing the code in is a very important factor in this discussion.  I would argue that some languages allow you to do more than others with a single line of "regular" code.  The functional density is clearly going to affect the rate at which lines can be produced, and the amount that must be produced in order to complete the given task. 

In short, we need to have controls on the data that we are presenting.  Just the # of lines of code alone is about as descriptive as saying the law of gravity is "things fall."  All of the factors involved are not enumerated or fully understood.
Joshua Volz Send private email
Monday, January 09, 2006
"I would argue that some languages allow you to do more than others with a single line of "regular" code."

Definitely. Just yesterday I wrote a line of Perl code. Note that this is native Perl, no libraries involved:

return ( "(" . join(",", sort(keys(%$Ref))) . ")" );

$Ref is a reference to a hash with a key-value mapping, e.g. ("b"=>0, "a"=>1, "c"=>2). The line returns a string with the sorted keys, separated by commas: "(a,b,c)".

Now try to implement this with native C. First we need to write a hash table implementation...

"1) availability of API libraries or other code base (components, reusable code etc)"

+1 to this.
Monday, January 09, 2006
Repeat after me:

Lines of code per day is not a measure of productivity.
Lines of code per day is not a measure of productivity.
Lines of code per day is not a measure of productivity.

The most productive programmers get the same job done in fewer lines of code.  It can often be very productive to *remove* lines of code from a system.

Lines of code is only a measure of the cost of maintaining the system, not the productivity of the programmers.
T. Norman
Monday, January 09, 2006
Well, the original poster said, "I am not arguing that lines of code is the best measuring stick of productivity (incidentally, I don't think it is)."

I do think that (time / line of code) means something... For example it kinda supports the assertion that less LOC could mean higher productivity, if it took less time to write those less lines.

Haskell is weird that way though. I get the impression (and I don't have that many datapoints, so take this as you will) that they sit and think, with pen & paper, about how to simplify a problem, then ooze out a very distilled solution. Takes a while, but those solutions can be pretty slim and clever.
Tayssir John Gabbour Send private email
Monday, January 09, 2006
First, I agree with T.Norman. That said, a measure is a requirement in many houses, so if you must.

Lines of code:
 - Never across multiple languages.  1000 lines of C++ code does not equal 1000 lines of ADA.
 - Never across a short unit of time.  Lines of code per day, week, or month are about useless. LOC is an aggregate not a point in time measurement.
 - Agree what counts as a LOC.  The best measure is language statements.  This stops language abuse.
 - Beware the law of unintended consequences. Documentation is not a LOC so why should anyone bother?

Function points:
 - Never across multiple languages unless you are evaluating languages and the tasks are identical.
 - Unless you have been trained, and have done it before, you are probably calculating FPs wrong.
 - Always document how a FP was derived.  While, in theory, it is not subjective - it can be.  As long as everyone agrees to measure an API call the same way, no problem.
 - Aggregate the data. 
 - Philo also makes a valid point, about abuse of the system.  However, it would be an unusual system that counted date validation as a FP.  So be sure you agree when measuring.

In your title you said LOC per "time."  That is good as long as you do not make the time a small one.  In addition, beware of those who count LOC or FPs on maintenance.  Those require a different, and I have yet to find a good, measurement system.  Debugging a complex problem for three days to find out that someone forgot to initialize a value is _not_ 1 LOC in 3 days.
Monday, January 09, 2006
> Now try to implement this with native C. First
> we need to write a hash table implementation

That is certainly beyond my capabilities. As is the sort. And if I did write them I would certainly never be able to use them again so that I only had to write them once anyway.
son of parnas
Monday, January 09, 2006
Why shouldn't spending 3 days to track down one bug count in your LOC average? I can write an almost unlimited number of LOC's per day if I don't have to worry about whether the code is buggy or not.
Monday, January 09, 2006
Grant - As part of normal development we have included it.  I was referring to problems handled by someone other than the original coder. 

A client calls and says when they unplug the network card, while the PC is running, and then insert it back in, the application will not respond.  The person tracking down this issue may spend three days to add a call to the reset method. 

In theory, that should be used in the aggregate of the original development, but you really need to be keeping good metrics to be able to do that.  My fear is someone would use that to show that Dave Debug only managed 1 line of code over three days.
Monday, January 09, 2006
Absolutely I agree with everyone who says that LOC is not a good measure.  It's not portable across languages (possibly not across projects because of library use or stylistic differences), it's easily subject to abuse, there are clearly cases where negative numbers (removing lines of code) are highly productive, etc.  The sole virtue of LOC seems to be that it is easy to collect and measure (and the measurement part is debatable, because LOC can be so easily abused).

And yet, anecdotally, LOC works well for some groups as a measure of productivity.  Perhaps it's just because something is being measured and that effects how people work.  Perhaps it's because LOC is a better measurement than hours in your chair (which is the default measurement many bad managers use).

Function Points make more sense, but they seem very "heavy" (especially to people in the game business, which is where I try to improve life) and their initial implementation was not well-suited to process-heavy implementations.  And I can't quickly get my hands on a copy of their current manual without shelling out a few hundred dollars.  (Not, IMO, the best way to spread the word of a valuable development technique -- but obviously a decent way to make money consulting on it :-)).

Joel's post about "Hitting the High Notes" ( discusses data from Professor Stanley Eisenstat at Yale who collects information on how long his students work on each project and how many automated tests the resulting program passes correctly.  Dr. Eisenstat is clearly collecting valid information about programmer output (number of tests passed) and productivity (number of tests passed per hour worked), although there may be some question about the time spent since it is self-reported.

The "Real World" doesn't typically allow us access to that kind of data: neither the problems nor the solutions we face are nearly so well defined.  As a result, we search for a proxy measurement of productivity.

If LOC is not good, and hours in chairs is not good, does anyone have a nice proxy that's not too heavy?
Evan Robinson Send private email
Monday, January 09, 2006
+1 for Philo.

I've never gone by the LOC statistic for any reason. It's pretty much worthless. I prefer to judge based of what I accomplished, unit tests passed, etc.

Besides, the working environment you're in and your role will affect the amount of code you write in any given day. Are you working on a mission-critical app? Defense contractor? Embedded application? Are you involved with design, bug fixing, architecture, etc.?

I have days where I'm doing documentation all day, but some where I'm mostly writing code. Sure, I'm not the fastest coder out there, but the code I write is robust, well documented and it WORKS.

I had one project where I was supposed to make our current installer better. It was an MFC dialog application, which at the time it was dog slow, taking 3 minutes and a was a whopping 10MB in size. My boss wanted me to make a smaller version of it for easier downloading and making it more reliable, as he didn't like it one bit.

After going on my "search and destroy" mission, I ended up removing roughly 50,000 lines of bloat and unnecessary code (some of it was the usual MFC boilerplate crap, but you get the idea), got the speed down to 8 seconds dead for a full install and with a final size of 52K.

Sure, my LOC statistic would suck, but then again the results speak for themselves...
QADude Send private email
Monday, January 09, 2006
My position is that LoC is not really a good measuring stick for programmer productivity.  It is a reasonable aggragate number though, and you can (ab)use it to let the managers know you are actually doing something, even though they can't see it. 

I would say that LoC *plus* a context can give you some information about productivity, mostly in the anecdotal sense and mostly useful when speaking with other programmers.  For example, if I tell you that my job was optimize C++ code that was running slow and I tell you I removed 14 lines of code over three days, resulting in a net increase in program run speed, then people who program in C++ a lot can tell how much work that was.  It is easy to make other programmers understand the order of magnitude of the work given LoC and context.  If I tell you I am writing C# forms and I wrote one that was 9,000 LoC (or 9KLoC if you like) then another C# programmer has some idea what that would take.

On a completely different note, LoC is a better measure than most I can think of for finding out how much time the programmer spent typing.  This is important, while typing is clearly not the only thing we do, it is something that we do as part of most projects (optimization, bug fixing, etc are light on typing - which is why context matters).  I would argue that if the programmer had to type a lot of lines of code (for creation projects, debugging, optimization, etc are not what I am talking about here), that would mean that the overall project took longer than if he didn't. 

I would further argue that typing time has the largest impact on finishing time in medium sized projects.  Small projects require very little typing by their nature.  Large projects require lots and lots of thinking, planning, designing, whiteboarding, et cetera and therefore the typing time is a smaller portion of the overall time to finish the project.  With a medium sized project though, the design can be straightforward but still require a proportionally larger amount of typing.  In these instances, LoC + context might be used as a rough estimate to approximate the amount of work because a large portion of the work is typing.
Joshua Volz Send private email
Monday, January 09, 2006
==> Lines of code per day is not a measure of productivity.

I couldn't agree more, but since the OP asked ...

Usually, a good day is about 1,000 lines of C# code -- that's "heads-down-writing-code" all day. Now, when you factor in: client-site visits for discover of requirements, documenting said requirements, estimating the project, designing the system, handling DBA tasks, handling basing network admin tasks (setting up users/groups/whatnot) installation of needed client software, writing use-cases, documenting test cases and results, monitoring the backups (of the database, file system, code repository), handling user training, taking a few phone calls from clients to put out fires, and the occasional tracking down of miscelaneous bugs, missing files, jobs that failed ... You get the picture. When you add it all up over everything we do here as developers, it ends up being less than 100 lines per day of good, solid, tested, production-ready code.

Not that LOC really matters for diddley-squat anyway.
Monday, January 09, 2006
There's no way to measure productivity. It's simply impossible so don't even try. And without knowing productivity, there is no way to estimate how long it will take to do anything or how much it will cost. Such a task is simply impossible. No one has ever estimated how much something will cost or how long it will take. You just have to accept however long it takes - maybe it will be forever if you are unlucky. This is why luck is so important. Those of you who do not have a rabbit's foot should invest in one now. It is the best investment any project manager can make.
Art Wilkins
Monday, January 09, 2006
Wow Sgt Sausage averages 250,000 handwritten lines of code a year. That's quite impressive. Most of the best programmers I know do only 35,000 or so. The industry average has been measured at 3250 lines of code per year.
Art Wilkins
Monday, January 09, 2006
You did not read Sausage's entire post because he narrowed it down to about 25,000 after all the other stuff that needs to be dealt with.
Tuesday, January 10, 2006
The industry average also considers that over the course of the year a programmer will spend more time in meetings, testing, estimating, debugging, dealing with clients (could be internal clients), documenting, playing solitaire, etc.  At the end of the year they'll average 20 or so lines per day, but during the coding-heavy periods they'll do over 100 per day.
T. Norman
Tuesday, January 10, 2006
One line of code every few years during
my productive years. I still remember a
hard project I did.

E = mc**2

I know. Not a high line count but I think
it was a harder problem than the surface
area of a cube project.

A = 6L**2

I know, they both have two variables, one constant
and a square.

Maybe I just suck as a programmer.

Yours truly,
Albert E.
Dan McDonald Send private email
Tuesday, January 10, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz