Given a situation where you have 2 projects that in total will provide enough work for a month for 6 developers in a ratio of 2:1.
Is it better to assign developers to each project and then they work on that project for the whole month or is it preferable for the whole team to work each project in turn?
What reasons do you have for your opinions?
Edit To clarify, they are entirely separate systems.
It depends a lot on how related the two projects are. If they have a lot of similarities, I would say tackle them as two projects within one large group.
If they mostly unrelated from a code and architecture standpoint, it would make more sense to split into two teams for the duration of the two projects, perhaps cross-training some of the developers as is possible.
If you're an Agile shop, just run two concurrent iterations.
The answer to this really depends on a lot of factors. If you're 100% certain that you won't lose a developer, and that no one will go on a long vacation, then splitting it into specific teams has some advantages. OTOH, if you don't know that for sure, it might be better to have the whole team work on each project.
Next, you have to consider deadlines - will running the projects sequentially increase your risk of missing a deadline on either one, and if it does, is that risk acceptable?
Of course, there's always the potential for developers to step on each others' toes. 2 man-months (yes, I know it's a myth) of work split amongst 6 developers is a little over one week's work per person - if that's reasonable for the size of the project, then that's fine. However, there is a limit to the size you can split the work into and still make sense.
Answer those questions for your project, and that should give you a decent answer.
I think that in the case of unrelated projects you will have a far better efficiency if you split your developers across projects. This is because there is overhead in communication, if you double the number of developers on a project you don't half the time it takes.
However if your developers need to learn both systems eventually then this overhead needs to happen at some point. time constraints should dictate whether that occurs during or after the project.
If the projects are in separate systems I believe it is wise to separate the developers working on the projects since humans are not entirely great at multitasking because our context switching skills are slow. So either they work one project after another or split up the team to each project.
I would split them into 2 teams assuming that there are enough developers to cover each project (Each project gets 3 developers and 3 developers is enough for each project). I don't think it's effective to put more developers on a project than is necessary.
Edit: This is not taking into account all the many other factors that go into this type of decision (developer productivity, skill, availability)