Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a large project you only get to use the technology necessary for that project; smaller projects come and go, and you need to learn more technologies.

On the other hand large projects are usually complex and thus hard; if you are used to hard projects then you should manage to perform well on smaller projects.

So, in the long term is it better to work on small or on large projects?

share|improve this question

closed as not constructive by Jarrod Roberson, GrandmasterB, BЈовић, ChrisF Jul 11 '12 at 12:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

A mixture of both seems to be the best choice. – karan k Jul 11 '12 at 6:40
yeah become generalist try as much as you can ;) – Michal Franc Jul 11 '12 at 6:41
specialization is for insects ( and Windows developers ) with apologies to Heinlein. – Jarrod Roberson Jul 11 '12 at 7:11
Whats better would depend on your personal preferences & specific opportunities you encounter. – GrandmasterB Jul 11 '12 at 7:36
As long as you ship! – user1249 Jul 11 '12 at 10:11
up vote 9 down vote accepted

Size doesn't matter, success does!

Working on projects with valuable mentors that can accelerate your judgement and experience and that are successful at pleasing customers is the most important thing you can focus on career wise.

Working on project after project that is a failure will teach you things but in a backwards way that takes a very long time to understand. Working on long drawn out projects that are failing is the same thing.

Size of the project doesn't mean complex or simple. It doesn't mean more or less new things to learn. Complex and "hard" projects are usually due to mismanagement, overly complex design and architecture and the like, this can apply to multi-week projects as well as multi-year projects.

Good Enough and YAGNI

There are a great number of projects today that don't have long shelf lives. There are web projects that may only be in production for a few weeks or months depending on the lifecycle of the need of the software. Think promotional micro-sites that are temporal in nature will be thrown away and never updated or maintained.

Learning how to scale down your Architecture Astronaut tendencies and do just enough to scratch an itch is a very rare and valuable skill today.

Not that Good Enough and YAGNI don't apply to longer lifecycle projects, but scaling down process and methodology is much harder than scaling up.

Specialization is for insects

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Robert A. Heinlein

Apply the above to software development and you won't go wrong. Being competent at many things will insulate you from fads and fetishes in the industry and ensure you are more employable than people who are one trick ponies.

share|improve this answer

I think it is very useful to work on a large project. As one learns a lot of aspects of Software Engineering in large projects, which includes but is not limited to:

  • Organizing code for
    • Reusability
    • Maintainability
    • Extensibility
  • Team work
  • Project Management

When you say you get limited to technologies, you probably do, but you can switch projects/jobs/roles once the interesting parts of the project is done. This is usually when the project has gone into production. After a cycle or two of updates you might start getting bored with the technology

The experience on a product is very different. One has to think of a lot of aspects for an update e.g.,

  • Backward Compatibility
  • Data Migration

Technologies come and go anyways but the experience of building a large project will always be useful. That said, whenever you are going to venture with a new technology, having experience of having built small projects in the technology will act for risk mitigation when you get to build a large project in it.

share|improve this answer

I would like to make a few points not yet mentioned in Jarrod's and Ozair's otherwise good answers:

  • Large projects tend to have a longer lifecycle, thus maintainability is a key concern. (Small projects can also live long, but IMHO it is less likely... moreover these often grow larger over time.) In small projects, you are less likely to (be forced to) learn how to write maintainable (= modular, clean, testable, SOLID) code.
  • Large projects tend to involve larger development teams too, plus a lot of other people (various managers, QA personnel, technical writers, etc.) which means communication (on many levels) is more essential than in a small project.
  • Large projects tend to slow down over time (due to a larger team, usually part of a large organization, and the long lifecycle), getting more and more into maintenance mode. This may be less glamorous, nevertheless an important part of the SDLC. However, this also means that chances to learn new technologies get limited. (OTOH, as suggested above, there is an awful lot more to SW development than technology...) And usually it also means more bureaucracy and less agility :-(
share|improve this answer

Quick answer would be: It depends.

Both big/small projects has their specific flavors for developers involved in it. The main difference is in project management approach and scope of the project. From developer point of view, it is more of building infrastructure code to handle common use cases to support your project in long run.

Smaller projects tend to be one-man team with very little design time and aggressive deadline :)

share|improve this answer

My Preference is to work on a complete project either it is small or large. We should get complete understanding of the project, get involved right from the beginning till its sunset. Also we should play multiple roll in the project so that we can understand a Project Life Cycle Better.
With Respect to Time Frame it is better to start with small projects and learn them completely, later go for Bigger/Large Project and try to learn them. Usually it will be different to learn Large Project. But if you have intial experience with Small Projects that will help you to understand Large Project Quickly

In Summary : Start with small projects, learn thoroughly and then settle in large projects.

share|improve this answer

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