Just out of curiosity what's the difference between a small, medium and large size project? Is it measured by lines of code or complexity or what?

Im building a bartering system and so far have about 1000 lines of code for login/registration. Even though there's lots of LOC i wouldnt consider it a big project because its not that complex though this is my first project so im not sure. How is it measured?

  • 2
    Yes............More complexity means more lines of code. Commented Nov 5, 2010 at 18:13
  • 3
    The first KLOC is the hardest...
    – user1249
    Commented Nov 5, 2010 at 18:17
  • Next you have to ask "What makes a project complex? Lines of code? Layers of abstraction?" Commented Nov 5, 2010 at 18:19
  • You mention 1,000 lines of code as a "lot." That really doesn't mean anything without context. I have worked on several projects that had well over a million lines of code. I've also worked on what I would call "small" projects that only have 50,000 lines or so, but because of the complexity they would not be thought of as "small" because of the amount of resources they required to design, code, and test. But in my personal experience, I can't think of any case where I would consider 1,000 lines to be a lot. I only mention that to provide some perspective for your fist project. Good luck!
    – TMarshall
    Commented Feb 19, 2011 at 23:59
  • I would say that "bigness" of a project depends on more than 1 factor...
    – kiwixz
    Commented Feb 6, 2015 at 11:38

11 Answers 11



The more complexity, the harder it is to learn everything in the project.

  • 6
    That's similar to a tautology imo. A complex system is a synonym for large system; unless talking about code-complexity and then it may very well be so that everything is well decoupled and has a single responsibility, in which case code complexity might actually be lower for large projects. Hence, saying that complexity means that the project is big is really saying nothing.
    – Henrik
    Commented Feb 19, 2011 at 23:23
  • ...or naturally any other measure of complexity.
    – Henrik
    Commented Feb 19, 2011 at 23:25
  • @Henrik, "complex system" is not equivalent to "large system".
    – user1249
    Commented Feb 20, 2011 at 0:13
  • 1
    No, it's a synonym.
    – Henrik
    Commented Feb 20, 2011 at 9:28
  • @Henrik, I do not agree. A system can be large but regular - i.e. many things are solved in almost the same way, where you can predict how things are done based on your experience with the rest of the system - and a system can be small but still very complex.
    – user1249
    Commented Jun 19, 2011 at 7:53

Roughly how I'd accord things -- keep in mind this is more or less arbitrary. The "size" of the project in a composite of other factors like complexity, source lines of code, number of features/business value, etc. A very small product can deliver a large amount of value, etc. That being said:

  • 2m+ sloc is a large to huge project. These are generally so complex that few if any people are 'fluent' in the entire system; rather responsibility tends to be modularized along the structure of the code. These projects often deliver enormous business value and may be mission critical. They are also sometimes under a heavy strain of technical debt and other legacy concerns.

  • 100k - 2m sloc is a medium-sized project. This is my middle ground: the project is complex enough to require some expert knowledge, and has likely accrued some degree of technical debt; it is likely also delivering some degree of business value.

  • 10k - 100k is a small project, but not too small to have enough complexity that you will want expert consideration; if you are open source, consider getting people you trust to review your commits.

  • Anythings less than 10k sloc is tiny, really. That doesn't mean it can't deliver any value at all, and many very interesting projects have very tiny imprint (e.g. Camping, whose source is ~2 kb (!)). Non-experts can generally drive value concerns -- fix bugs and add features -- without having to know too much about the domain.

  • 4
    I'd up-vote this twice if I could. The numbers are kind of arbitrary of course but I think the descriptions of what different degrees of "bigness" imply are spot-on. Commented Nov 29, 2012 at 3:06
  • 1
    @EricAnderson It is definitely easier to think of this in terms of the descriptions than the measure of sloc. A 100k sloc Erlang program is easily an order of magnitude "larger" than a 100k sloc C++ program, based simply on what it does regardless how easy the code is to read at a higher-level. At a certain point reading the code isn't even as hard as just remember what is going on inside the system at a high level because there are so many features and logic centers.
    – zxq9
    Commented Oct 21, 2017 at 8:19
  • @zxq9 I kind of disagree. True, that implies that the language choice could make a big project smaller. What used to big computers are now too slow, and what used to big software projects can be trivial nowadays. What is invariant is the cost/complexity of a project. While SLOC is not a perfect measurement, it is still closely related to the cost and complexity of a software project.—Just like big machines are not necessarily better, big software projects are not either. If possible, split a project into independent components, and choose the right technologies to make them even smaller.
    – Yongwei Wu
    Commented Aug 5, 2019 at 3:53

A project's size is measured by the degree of unmaintainability.

  • 2
    That's pessimistic :D
    – Henrik
    Commented Feb 19, 2011 at 23:21
  • ....and that measurement is? Commented Jun 19, 2011 at 9:42
  • 1
    @Casey Patton the measurement is literally the cost of maintenance.
    – mojuba
    Commented May 11, 2015 at 8:16

Complexity which may be estimated in a few ways:

  1. Budget. A project with a budget of $10,000,000+ is probably quite different from one that is under $10,000 for example. This can include labor, software, hardware, and other costs incurred in doing a project.
  2. Person hours of work to complete the project. Will it take a million hours or something else? This could also be seen as a time line factor where some projects may take years that I'd say were big compared to others that may take less than a week. Note that the person hours can be misleading as someone may think by doubling the staff so there are twice as many working on the project then the schedule can be sliced in half which rarely would work to my mind.
  3. Amount of hardware, other systems and people using what the project is building. If something is tying into 101 systems then it is likely to be more complicated that if it stands alone and doesn't tie into anything else.

While requirements can sound like a nice way to measure this, there are often more requirements that will be found as a project is done assuming a non-Waterfall methodology I believe.


A project size is probably best measured by the number of requirements the system has, where the requirements can't be reduced down further.

Of course, more requirements mostly means more complexity, but it's not always the case.

  • 1
    That may not be a good measure: requirements for compilers and OS kernels may be disproportionately big compared to other types of products.
    – mojuba
    Commented Nov 5, 2010 at 18:25
  • 2
    @mojuba: "Big" is quite a broad term, I'd imagine that writing a compiler or an OS would be a "big" project
    – David_001
    Commented Nov 5, 2010 at 18:30
  • @David_001: take the Turbo Pascal compiler, f.ex., whose binary size at one point was 70 kilobytes and yet TP was a full-blown object oriented programming language. We've never seen the sources but a 70kb executable can't be a big project.
    – mojuba
    Commented Nov 5, 2010 at 18:42
  • @David_001: not that I completely disagree with you in general. Any definition of a "big" project will be as vague as the word "big" itself.
    – mojuba
    Commented Nov 5, 2010 at 18:44
  • @mojuba: When I used Turbo Pascal, it wasn't object-oriented at all. Commented Nov 5, 2010 at 21:08

I'd measure a project's size by how difficult it is to see the whole project as a single big picture. For example, I have an exploratory/prototyping codebase for a machine learning problem I'm working on. It's only 5k lines of code, but it feels like a huge project. There are tons of configuration options that interact in unpredictable ways. You can find just about every design pattern known to man somewhere in the codebase to manage all that complexity. The design is often suboptimal because the thing grew a lot by evolution and isn't refactored as often as it should be. I'm the only one that works on this codebase, yet I'm often surprised by how things interact.

On the other hand, one of my hobby projects has about 3-4x as much code, and yet it feels a lot smaller because it's basically a library of mathematical functions that are mostly orthogonal to each other. Things don't interact in complex ways, and it's pretty to understand each function in isolation. It's easy to see the big picture to the extent that there is one, because there's not much of one to see.


Arbitrary answer: How big the project is how much you wish you had done it with event-sourcing and SOA from the start. Or that the authors of the system had read Evan's book "DDD: Tackling Complexity in the Heart of Software" ;)


Compexity & Scope

Complexity and Scope I believe are what determines how big a project really is. However, there are several intangibles that can effect the size of a project as well.


The biggest downfall I faced was lack of requirements. In my particular situation the sales manager was determining requirements. His focus was on the sale... gotta get the sale. In his mind what the customer was asking for didn't seem all that complicated because we had built something similar. Vague requirements lead to underpriced jobs and over committed expectations.

Lack of a CCMU

CCMU is what I call a "Coo Ca Moo" (Clear Complete Mutual Understanding). You need to have a CCMU with your customer.

If you have a small project with a poor CCMU then you can wind up doing the project 2,3,4 or more times. Thus a simple 20 hour job turns into a 60 hour project with a stressed out staff and a very dissatisfied customer.

Scope Creep

This happens more often than you think. The customer decides that since you are already doing A, B & C it shouldn't be that difficult to add D or even F. If this behavior is not checked it can also turn a small project into a medium size project. And depending on how the sales manager sold the job these scope creep expectations may seem "FREE" to the customer.


Its strange, reading a lot of these answers I find I view the size of a project very differently. Perhaps it is my working in a large corporation but I tend to view the size of a project as more of a scale of its visibility/desirability to its clients (depending on your area of work these can be coworkers or actual paying customers).


Complexity is the right answer, but how to estimate it?

Factors are :

  1. Extension points count
  2. Modules layers count (functions, classes, class systems, libraries, shared libraries, applications, network applications, etc.)
  3. Dependencies count (platforms included)
  4. Features interdependance count.
  5. Necessary non-code resources (including graphics/arts, driving scripts - like level design scripts - and other resources required to complete a version of the application).

The more you have of those, the more complex is the project.


LOC is notoriously inaccurate for a lot of measurements, but I think you're trying to measure something that there really isn't an accurate way to measure. Perhaps an alternative might be cyclomatic complexity.

Ultimately though, I think "bigness" of a project is difficult to quantify. It's almost like asking how you determine if a dog is big or not. Not only are there multiple ways to measure it (mass, volume, etc), but I personally don't find it very useful. Reality is that my criteria is probably going to be something like "How likely am I to run from this dog if I see it in a dark alley?"

And for the record, I generally wouldn't consider 1k lines of code to be a lot. It would be a sizable chunk of code, but it wouldn't be that much in the grand scheme of things. Of course, I suppose it does depend on the language. For instance, 1k lines of code is much less code in a language like C than it is in a language like Pyhon.

Not the answer you're looking for? Browse other questions tagged or ask your own question.