Calculating how much time you can save by estimating the code you write in a year [closed]

Question

I'm looking for real figures and experiences, please don't take this too subjectively:

While looking for something else, I happened on an interesting statement, which partially reads as follows:

[...]the national average is 9,000 lines of code per year per person.[...]

I write a lot of code, but not full-time. When I look back at my projects of the past year and I do a (very) rough count (counting only code lines, no comments or white lines) I come to about 19.000 for a year that make it into a project. If I can automate parts of that, I could deduct the profit in time and money.

For estimating time-saving for larger projects, I need averages. How many code lines does man write in a year, on average, in C# (or other language of choice)? And, looking at your own situation, would you consider your hand-written code could (partially) be automated and by what gain?

Answer 1

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).

Answer 2

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.

Answer 3

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.