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?

Vinia

10 lines of assembly is not the same as 10 lines of C is not the same as 10 lines of Ruby. – Cureall

Just a little remark: did anyone know that the OS/2 vs Windows debacle (IBM vs Microsoft breakup) was partially a result of IBM measuring productivity by lines of code, which frustrated Microsoft's programmers? en.wikipedia.org/wiki/OS/2#Breakup – Vinia

Obligatory xkcd: 1 2 3. – Flurried

Answer 1

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.

Harley

Very interesting and well worded. Thanks. I especially like the pointer to Function Points, which I needed when PM'ing (part of) a huge project of the Dutch Government, where everything was measured in FP's (and it kinda worked: if you added a factor 2.4 to it, but that's a long story... ;-) – Vinia

@Abel:A factor of 2.4 is actually quite a bit better than most methods even hope for. If you try to base things on lines of code, you'll generally be lucky to get much closer than a factor of 5, and being off by a factor of 10 isn't all that rare. – Harley

Answer 2

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

Thug

(I only spent few days/month coding, the daily avg is different) I think you have very interesting points against automation. Using data mapping auto-generation software saves me writing POCOs and the generic classes (S#arp architecture). Implementing INotifyPropertyChanged for each property could easily be automated. Andrew Hunt in Pragmatic Programmer? Says "automate where you can". Good automated code generation should save time, but should be tested in its own right. – Vinia

Btw, I apparently was a bit sleepy yesterday, or you: 19000 / 36 = 527 days? ;-) – Vinia

Yeah, I think the math seems really off. When I divide the LOC in a shipping product by the man-hours spent on it I tend to get something in the area of 1-4 lines per day. At any rate, removing boilerplate instead of automating it should be the primary goal--it's the difference between harming your project and helping it. I've almost always been able to find a way to get rid of it--for instance I really dislike access objects and will replace them with data structures or something similar. I just continually look for practices that allow me to write factored code. – Thug

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.

Trouveur

Answer 4

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.

Lisp