Use of LOC to determine project size

Question

How many lines of code (LOC) does it take to be considered a large project? How about for just one person writing it?

I know this metric is questionable, but there is a significant difference, for a single developer, between 1k and 10k LOC. I typically use space for readability, especially for SQL statements, and I try to reduce the amount of LOC for maintenance purpose to follow as many best practice as i can.

For example, I created a unified diff of the code I modified today, and it was over 1k LOC (including comments and blank lines). Is "modified LOC" a better metric? I have ~2k LOC, so it's surprising I modified 1k. I guess rewriting counts as both a deletion and addition which doubles the stats.

Answer 1

A slightly less useless metric - time of compilation.
If your project takes more than... say, 30 minutes to compile, it's large :)

Answer 2

Using Steve Yegge as the benchmark at the upper range of the scale, let's say that 500k lines of code is (over?) the maximum a single developer can maintain.

More seriously though; I think once you hit 100k LOC you are probably going to want to start looking for re-factorings before extensions to the code.

Note however that one way around this limit is obviously to compartmentalise the code more. If the sum-total of all code consists of two or three large libraries and an application, then combined this may well be more than you could maintain as a single code-base, but as long as each library is nicely self-contained you aren't going to exceed the capacity to understand each part of the solution.

Answer 3

In my opinion it also depends on the design of your code - i've worked on projects in the 1-10K loc range, that was so poorly designed, that it felt like a really large project.

But is LOC really an interesting meassure for code? ;-)

Answer 4

Maybe another measurement for this would be the COCOMO measure - even though it is probably as useless as LOC.

A single developer could only do organic projects - "small" teams with "good" experience working with "less than rigid" requirements.

In this case, efford applied in man months are calculated as

2.4 * (kLOC)^1.05

This said, 1kLOC would need 2.52 man month. You can use several factors to refine that, based on product, hardware, personel, and project attributes.

But all we have done now is projected LOC to a time measurement. Here you again have to decide whether a 2-month or 20-month project is considered large.

But as you said, LOC probably is not the right measure to use. Keywords: software metrics, function points, evidence based scheduling, the planing game.