Multiple projects - similar platforms or as different as possible?

Question

When working on multiple projects simultaneously (for the sake of simplicity let's say half time each on two projects), which is better? Should the two projects

• Use the same language? Same/similar frameworks?
• Use entirely different languages?

Additionally, is it best if they are target for similar platforms, or different (web v. desktop v. mobile v. utility library for internal use)?

The first responses that come to mind are

• They should be similar, and play to the strengths of the developer to help him handle managing both of them
• They should be as different as possible to help the developer keep organized

Since I've never done this in a professional setting, I was hoping more experience programmers could shed some light on the best way to go about doing this.

EDIT:
This question is assuming the existence of multiple other projects, each of which is underway (I think some underway and some brand new with no design decisions yet made would be too broad for one question). When choosing between existing projects for a second project, should a developer consider how similar his new project is to his current project, and how should that affect the decision?

Answer 1

First of all, the actual requirements should drive the decision behind what language, frameworks and tools to use.

If the requirements allow you to work on similar languages, frameworks and tools, then you should definitely try to keep things as consistent as possible.

You want to keep things similar for the following reasons:

• Less context switching for a developer is good - There is a lot less context switching when you allow your devs to use the same languages, tools etc... All they have to switch is between 'domains' but not between languages with different syntax and/or completely different principles.
• Development environment complexity is less - It is complicated enough to set up your dev environment for a single kind of application stack, you do not want the pain of having to set up more than what you have to.
• Consistency is good - Keep as much as possible consistent between the two projects, like coding standards, directory layouts, etc. Imagine a new dev coming onto the project and trying to understand both apps. They would require twice the ramp-up time.

UPDATE: The question changed significantly, and my understanding is that you are asking the following...

I have a project that I am working on right now. I would like to pick up another project to work on simultaneously with the other. Is it better to pick a project that is similar to the existing one, or a completely different one.

This depends entirely on what you want to get into.

Do you want to learn a new language altogether? I would focus on the new language. I personally do better when my focus is not divided between projects so I like to work on a single thing at least for a couple of days before I switch to something else. As far as the type of language is concerned, if you learn something that is close to the original one (Java->Groovy), you will probably pick it up faster, you will have less frustration and less context switching. However, you might not get a great perspective on how much two languages can really differ (Java->Ruby or LISP->C) in their principles.

Answer 2

Assuming these decisions have passed the "use the right tools for the job" stage, and you're genuinely faced with a situation where there are equally useful projects with equally useful tools for each that the developer knows, my thoughts:

I have rarely, if ever, found myself benefitting from working in two entirely different mindsets at the same time. Some reasons I dislike it:

• Different assumptions about the final application. It's hard to switch your mindset in between two entirely different setups. To use an extreme example, I find it irritating to be programming for something that's going to go on a cluster one day, and then something that needs to run in an extremely resource poor environment.
• Tool familiarity. Even if you're intimately familiar with both coding environments, switching back and forth takes some work. Where's the button to do X in this particular IDE? Does this language start indexing at 0 or 1?
• Consistency between projects. Your question actually assumes 4 projects the developer could split their time on, two sets of two similar projects. Presumably, those other projects will get picked up by someone else. It's probably better to have all the X projects follow Programmer 1's style and the Y projects follow Programmer 2's style (assuming they're not spaghetti code, well documented, etc.) than have a weird blend where when you need to work with X, you also need to figure out if it was Bob or Amy who coded this one.
• Lets say, as Joonas suggests, that you chose poorly. First, it's equally probable given no information that your choice takes off, so arguably its a wash. But even if you do have the ones you decided to go with collapse, it's probably better to migrate from the new to old platform/system/whatever at the same time - again, using consistent style, than have them ported over by two different teams.

Basically, I vastly prefer to focus on one "type" of project at a time. Put on my "R" or "SAS" or "Python" hat until that project is done, then out-and-out switch, rather than bouncing between them.

Answer 3

You should strive to use the best tools for the job at hand. However, if the best tools' usage are utterly unknown to the developers these may not be the best tools.

Answer 4

That depends on what you want.

• If you want to get as much work done as possible - choose similar technologies, to minimize learning time.
• If you want to learn new things, choose different technologies, to increase exposure to new ideas and technologies.

So it would depend on context.

If it were a hobby project, I'd probably lean towards option 2, because I like to learn new stuff.

If I were assigning developers to projects in a company, I'd try to find a compromise, because for an employer both points are important: You obviously want your employees to get work done, but you also want them to learn new stuff, so you can move them between projects as required.

Answer 5

On one hand, sure, for obvious reasons (less context switching, more consistency, etc.)

On the other hand, do you want to put all your eggs in one basket? What if the framework / platform / whatever of your choice somehow dies? What if the framework / platform / whatever that you didn't choose starts thriving? It does happen all the time, for example, with mobile platforms - currently the once mighty Symbian is slowly but surely going down, Windows maybe going up, but nobody knows what's the status quo in after a couple of years.

Answer 6

If these are multiple projects at your job or for your own business, its probably better to use a similar stack of technologies to enhance the chance of being able reuse parts of one in the other.

BUT, if one project is for work, and one is a personal project you are doing at home - that is, two completely different venues - then use separate technologies. Presumably code-reuse in that case is out of the question anyways, since you cant copy your employers code. By using a different stack you'll be less likely to 'burn' out on one or the other because you wont be looking at it for 12 hours a day.