Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as primarily opinion-based by MichaelT, gnat, Bart van Ingen Schenau, GlenH7, Simon Dec 16 '13 at 13:08

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Yes............More complexity means more lines of code. –  Robert Harvey Nov 5 '10 at 18:13
2  
The first KLOC is the hardest... –  user1249 Nov 5 '10 at 18:17
    
Next you have to ask "What makes a project complex? Lines of code? Layers of abstraction?" –  Steve Evers Nov 5 '10 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 Feb 19 '11 at 23:59

11 Answers 11

up vote 14 down vote accepted

Complexity.

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

share|improve this answer
1  
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 Feb 19 '11 at 23:23
    
...or naturally any other measure of complexity. –  Henrik Feb 19 '11 at 23:25
    
@Henrik, "complex system" is not equivalent to "large system". –  user1249 Feb 20 '11 at 0:13
    
No, it's a synonym. –  Henrik Feb 20 '11 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 Jun 19 '11 at 7:53

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

share|improve this answer
2  
That's pessimistic :D –  Henrik Feb 19 '11 at 23:21
    
....and that measurement is? –  Casey Patton Jun 19 '11 at 9:42

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.

share|improve this answer
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 Nov 5 '10 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 Nov 5 '10 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 Nov 5 '10 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 Nov 5 '10 at 18:44
    
@mojuba: When I used Turbo Pascal, it wasn't object-oriented at all. –  David Thornley Nov 5 '10 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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

Requirements

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.

share|improve this answer

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" ;)

share|improve this answer

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.

share|improve this answer
    
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. –  Eric Anderson Nov 29 '12 at 3:06

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