Some people would jump at the change to learn a new technology on the company's dime, if they know that the project failure can't be attributed to them. Eg, a front-end engineer could say "we developed an Angular2 front-end which was on-time and tested well, but the back-end engineers failed to <insert failure here>."
Do project failures really look that bad?
Kent Beck and Ron Jeffries famously employed worked on the Chrysler Comprehensive Compensation System, which helped establish Extreme Programming. https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
What does it mean then that after the first delivery, the project's customer representative was burned out and couldn't be replaced, the software was only ever used for 10,000 of the 87,000 people it was supposed to be used for, but even with the smaller number it still took 9 hours to run, and new developed stopped two years later, never reaching the original design goal?
If project failures look bad, how is it that XP ends up with such a good reputation?
I should have been more specific about the context: I'm talking about failed projects that were doomed from the start, and known to be in such a state by those that were involved. There are many (most ?) projects that look okay right up until the implementation when all the problems become visible. Those types of projects are fertile grounds for learning from experience, and I would categorize them as valuable experiences.
Obviously if a developer is in a junior position in a project that encompasses a small army of developers, then they may not have any problem with staying on with such a project. But, I would gather that these types of projects are pretty rare, and that most projects involve much smaller teams. In such an environment, the stress and toll on one's family life and health aren't worth sticking around for, even for any learning experience that one may gather from the failure. It's a much better situation to simply learn the involved technologies on one's own in your spare time than subject oneself to that level of harm.
Looking around now, https://www.quora.com/What-is-it-like-to-work-on-a-death-mar... summarizes what people do in these sorts of projects: "(a) follow all orders you are given, (b) avoid being given orders if you can (i.e. don't volunteer for more work), (c) always appear busy and productive, and (d) start doing side projects (and, possibly, looking for other jobs) to stay sane. A death march project can be a great time to build unrelated skills on the clock, because there tends to be a lot of downtime due to miscommunications. ... keep quiet, always appear busy, and focus on your own career vector."
This agrees with my understanding, which is why I don't think it's such a CV death knell as you suggest.
