sigh, I know I should just let this thread die but that would mean eightball gets the last word
Ok I give up. You are engaged in the most difficult collaborative projects in history...
...and I should be compensated accordingly!
But, I can't resist (mwhahaha!). As I brought up before, you do bring new people into your team as time goes on successfully. If those new people can add worth to your project, I'm not sure why you are stating this. I'm not advocating for bringing in 50 new people a week before the project is due; I'm thinking more bringing in a small number of people a few months before the due date. You can train them properly, then release them (monitored, of course) to help.
The difference is still that any work of any kind generates bugs that need to be cleaned up. For most professions, they have a specific body of work that they move through and that's that. Maybe there's some cleanup required, maybe there isn't. For coders, there is always
cleanup required. Any alterations to the code are extremely likely to generate new issues which then need to be cleaned up, and then there will be cleanup to the cleanup. There is a great deal of pain associated with moving from generating more bugs than you're fixing (because you're focused on specific functionality) to fixing more bugs than you're generating. New people will always weight the average in the undesirable direction.
And I'm curious to hear what you think about the crunch time thing I brought up. If coding is that sensitive, crunch time would seem to be the absolute worst thing for bugs. People functioning on no sleep make mistakes...and sleep deprivation is exactly what tht situation is in crunch time i, right? But from what I know (and obviously, I'm no expert on this subject) it seems almost to be a granted condition towards the end of development.
The thoughts of the game industry on crunch could probably fill up their own forum. I believe it is inevitable to some extent, yes. But I would differentiate between "good" crunch and bad crunch. Bad crunch is what you're describing. It does happen, and it ends up like you'd expect - badly. It can be an overzealous publisher pushing for changes late in the project, or simply bad management where you end up trying to cram in features when you should be locking things down for ship.
Good crunch is obviously a misnomer. Everyone wants to leave after their eight hours. But there can be crunch that's healthy for the product. The problem in your thinking that all crunch is automatically bad is in assuming that because hours increase, the expected work throughput increases. In fact, during a healthy crunch, I think the work level should remain constant, or actually decrease.
The reason is that towards the end of a project, testing everything becomes immensely important. As we've harped on above, any change can have unintended consequences. In an ideal situation, any change to any part of the project should require you to test the ENTIRE range of content. Because consequences can be unintended and unpredictable, you can't assume any change as being safe. Imagine the problem this presents for a game like Oblivion, where not only do you have a large amount of content, but a large amount of options in how you move through that content. Something as simple as changing the contrast on a texture requires the entire art archive to be rebuilt, and who knows what all could go wrong during that process, or where those problems could show over the course of the game. There are many issues that I could cite during Oblivion's development that seemed like easy fixes and had us pulling our hair out for weeks to come.
So what happens in crunch is that the time you spend on each individual issue goes way way up towards the end of a product. But it should NOT mean you are now throwing things into the code is a desperate attempt to finish. You have to constantly ask, do we need this? What does this do to our stability ratios? Is this fix isolated or does it touch a large number of systems? 99% of your time should be spent testing and investigating issues, and 1% should be spent changing stuff. When that percentage starts to skew, it means you're slipping closer and closer to deathmarch territory where you can't get control over bug generating vs. bug fixing, and the problem spirals out of control. This is the situation you're probably in if you're adding new people to the team at a late stage, trying to squeeze out that last bit of functionality. Bad idea. How is that avoided? Good management and competence
But it doesn't change the fact that the situation changes towards the end, and I think a lot of what people call "polish" comes out of those extra hours when you're really looking hard into the last few of your really nasty, long-standing issues.
Crunch does not have to mean sleep deprivation. That is bad, so we try to do reasonable crunches without insane hour requirements and with clear measurable goals. As with most things, there's plenty of room for improvement.