I participated in three projects that were clear failure. These were quite painful but looking back, two of three did not have negative consequences on my career, and even third one wasn't the end of the world.
Here are some observations I recall.
Developers at junior positions ("code per spec", "fix the bug", stuff like that) don't get affected much, unless they slack off due to lowered morale in the team. At positions like these, a sensible and even sometimes successful survival strategy could be just doing the best you could.
- For example, one of the failures I experienced has been overcome by plain, methodical fixing of more than hundred known bugs which (coupled with particularly smart approach of promoting this progress by tech lead) eventually led upper management to decision to recover the project and give it yet another chance with a new release, which in turn made a reasonable success.
Programmers at more senior, influential positions would better be prepared to share the negative consequences of project failure. An architect, tech lead, senior developer are typically expected to make an impact big enough to be considered responsible for project success or failure.
At senior position, one would better be prepared to gain from failure "indirectly", by analyzing what went wrong and what could have been done better.
These bits of knowledge, post-mortem lessons may be invaluable if learned right, the very successful career at senior positions may depend on how well these are learned, as explained in this brilliant answer at WP:
Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies...On a more practical note, one can consider "next / update release" approach as a possible way out of the failure. Coincidentally or not (I think not), but both of the failures that didn't damage my career went by very similar scenarios: release N was a total disaster, release N+1 was tolerable, releases N+2 and later were plain success.
Walking in your shoes, I would most likely put some effort in preparing / promoting the idea of "next release". Make (and communicate!) something like a tentative list of known issues that you would want to fix after planned release. Draft an informal, rough road map for next release(s).
Think of how you could communicate these ideas to people around you, how you could influence management to consider this plan. If the project has someone with good marketing skills, try to involve them into amortizing the failure damage by wrapping up coming release into smoother terms, like "early access", "beta", "customer preview", "introductory release", stuff like that.
Think of a backup plan in case if higher ups will appear deaf to this idea. Remember above story about "fixing of more than hundred known bugs"? there is a chance for things to change, really.
Management may appear deaf to next-release ideas now, but there is a good chance for them to reconsider in the face of strong convincing evidence of project quality progress.
- It is quite likely that there will be rather long time between freezing code for planned release and management decision to drop it completely. That time is your chance: if you focus effort on fixing known issues and properly "evangelizing" the progress, this could make a difference (as it once made to me).