Not to be rude, but that's a rather naive and shortsighted mindset. In fact, a major mistake developers or anyone working on group-based projects often face is when they're coming down to a deadline and things are looking dire so their superior just hires more people. That'll make things go faster, right? Well, besides the fact that these new employees must be trained and caught up to speed, are less proficient and knowledgable about what they're making and more inclined towards mistakes, or don't have a personality or views that jive well with the rest of the development team. This actually makes things worse and puts an even bigger strain on the previous developers because now they have to serve as trainers and glorified babysitters.

It's a mistake to believe that because developer(X) can do 40 hours of work in a week, that if X= 40, then X*2 = 80. Humans are not a stagnant X value, and their productivity flucuates depending on various circumstances.

I don't work in the video game industry, but I do work as a developer in a different field with projects of a much smaller scale. Generally it's one developer per project. But putting two on a project does not cut down timelines in half. It perhaps creates 20% more efficiency if nothing goes wrong, because it's not as simple as splitting the code in half and one person doing one part and the other doing another. We still need to discuss and coordinate at all times.

That's also not counting the fact that you're doubling the BUDGET as well by hiring so many people on, even if it's all at the start. You may be fine with a 50% paycut, but this is a lot of people's livelihoods and they don't have the luxury of picking a paycut over long work hours when supporting a family.

Not to be rude, but that's a rather naive and shortsighted mindset. In fact, a major mistake developers or anyone working on group-based projects often face is when they're coming down to a deadline and things are looking dire so their superior just hires more people. That'll make things go faster, right? Well, besides the fact that these new employees must be trained and caught up to speed, are less proficient and knowledgable about what they're making and more inclined towards mistakes, or don't have a personality or views that jive well with the rest of the development team. This actually makes things worse and puts an even bigger strain on the previous developers because now they have to serve as trainers and glorified babysitters.

It's a mistake to believe that because developer(X) can do 40 hours of work in a week, that if X= 40, then X*2 = 80. Humans are not a stagnant X value, and their productivity flucuates depending on various circumstances.

I don't work in the video game industry, but I do work as a developer in a different field with projects of a much smaller scale. Generally it's one developer per project. But putting two on a project does not cut down timelines in half. It perhaps creates 20% more efficiency if nothing goes wrong, because it's not as simple as splitting the code in half and one person doing one part and the other doing another. We still need to discuss and coordinate at all times.

That's also not counting the fact that you're doubling the BUDGET as well by hiring so many people on, even if it's all at the start. You may be fine with a 50% paycut, but this is a lot of people's livelihoods and they don't have the luxury of picking a paycut over long work hours when supporting a family.

I understand all that but you also can't expect people to work 7 days a week, 12 hours a day either. If having larger teams isn't the solution, there should be another one. People shouldn't have to work themselves into the hospital in the western world like they're in sweat shops.

Are you saying that other companies should become more like Nintendo?

And where did you get that conclusion from?