Sam at CodeOder.com asks a rather interesting question; asking which is much like opening a can of worms.
Sam's question seems like a simple question raised by an inquisitive mind; but scratch the surface of the question and you will realize it is not just a controversial question; but a question that can end up defining your character and life-style as a software developer. Sam questions:
We hear vague descriptions about project size tossed about all the time: Ruby on Rails is better for small projects. Java is for large projects. Skip the framework for small projects, but I recommend using one for large projects. What factors go into determining the "size" of a project?
Reflect on the question dear reader; and chances are that you might realize the problem in attempting to answer the question. You probably know this already. If you do not; ask anyone who has spent even a couple of years programming and estimating projects and he will tell you that:
- Simply counting LOC or number of lines tells you nothing about the project size. It is a ridiculous metric.
- Complexity is not indicative of largeness but just bad design.
- Large team size is not an indication of a large project but just an indication of bad management.
And so; if we as programmers; are going to take every metric out there and thrash it against the wall; how are we to then; dear reader; measure which project is large and needs special attention and which project is small and can be built easily?
As a young and budding engineer at Multiplitaxion Inc; years ago; I was a part of countless meetings where my ideas were turned down with stereotype remarks like - yes-we-know-it-worked-for-your-project-but-our-project-is-really-large.
Attending countless number of those meetings taught me that the difference between a large project and a small project can be described using this rather funny code snippet on the sun java forum:
'Large Project' usually does not mean or do a thing other than give you a warm and fuzzy feeling of being involved in something complex deep down inside; and that dear reader; is not such a good thing.
No; seriously; if there is one thing years of programming; software development; and software management has taught me; it is that if you are working on a 'large' project you are doing something wrong.
Now; stop drooling over how large your project is; how huge a team you have; and how many lines of code you have to write. Go ahead; break your next so-called-large project down into smaller components and start hiring kickass developers who can design each component like there were neatly cut pieces of diamonds.
I wish you good luck.