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?
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.
Complexity.
The more complexity, the harder it is to learn everything in the project.
Complexity which may be estimated in a few ways:
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.
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" ;)
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.
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.
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 :
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.
