First, lines of code written don t correlate well with actual productivity. At least in my opinion, if you want to measure and/or estimate productivity, function points are a more effective measurement. Second, when a metric varies over a wide range, the average generally means very little. In a case like this, a geometric mean generally means more than an arithmetic mean, but without (at least) something about the variance/standard deviation, it still doesn t mean much.

I d also note that there are some fairly sophisticated models that have undergone substantial research and even measured against real projects to get at least some idea that their results correlate with reality. For example, the COCOMO II model will generally produce much better results than just using lines of code per unit of time. There s at least one free online implementation (Edit: looking at it, this now allows either LoC or function point based modeling). There are also a tools such as SoftStar and Function Point Modeler) that combine a COCOMO-like model with function points to get what appear (at least to me) to be fairly solid results.

18000 would average out to about 36 lines of code a day.

With just 36 lines of code a day, what s the problem? The problem is debugging and rewriting your code.

NOTHING you can do to automate coding will speed you up--in fact, anything you can automate probably shouldn t be coded because if you are automating the typing of some pattern in your code, it should be factored out.

Where you can save time is to be more careful about how you code. Get your project through QA a little faster--code in a more explicit, typesafe language and code more clearly.

Also making your code data driven and fully factored wherever possible, although it will reduce the LOC you ship, it will make everyone s life easier and the project ship faster.

Do not EVER automate code input--if you can, you re doing it wrong!

Another way to think about it--every line of code you create has to be debugged and maintained. Why are you trying to come up with ways to give everyone MORE work when you could just create fully factored code (The input of fully factored code cannot be automated--pretty much by definition).

This is the type of metric talked about in the Mythical Man Month. Estimating projects in Man-Days/Months/Years, or counting lines of code as a productivity metirc guarantees inaccuracy in reporting.

I believe the rate for LOC highly depends on the technical debt in the project.

I have a project (SQL) which is 27KLOC (plus 4K more for support). Working on this code, over 7 months, I added 3K net new LOC to the project, with about 14KLOC written just for throwaway testing (testing to isolate anomalies, not unit tests).

Depending on how you measure, I write 29KLOC/year ((3K+14K)/7months*12months) but produce only 5KLOC/year (3K/7months*12months).

Looking at code (27KLOC) as debt, we have code that generates 7% (2KLOC) in throwaway code monthly, or 88% (24KLOC) per annum.

Assuming I can continue to turn out a whole 29KLOC/year, and assuming the cost of maintaining code stays at 88%/annum, my personal project limit is 33K lines of code. Beyond which, I will spend all my time paying interest on my technical debt, writing throwaway code, and producing net zero LOC.

Lucky that the last 3KLOC was a refactoring, which should reduce my interest rate.