Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not impose your conclusion on them.

Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south.

Having done that, keep working on the project in good faith.

Keep in mind, you may not know everything there is to know about the project, its backers, and financial decisions behind it. Management decisions that seem stupid to you might actually be based on smart reasoning that isn't visible to you.

Keep a paper trail (e.g. diary, saved emails, etc). Only include facts and objective observations. Leave all conclusions up to whomever (if anyone) reads what you've written.

As a developer, if you're not viewed as an obstacle to the project you're likely to come out fine from the finger-pointing that will no doubt happen. Your manager may not be so lucky, but that's not relevant here.

Just on general principles, update your resume and make sure you occasionally meet with other devs outside your company. If you're not part of any local developer groups, go join 2 or 3. It takes years to build up a network of friends and acquaintances but in the long run it's worth it. Be sure to look on it as a 2-way street - if you can help fill an opening in your company with someone capable, that's just as good as someone helping you find a job.

3 simple and cynical strategies to maintain career/sanity.

1. See a train wreck in the making - get off the train: Failing projects are terrible for morale and unless you have ninja upward management skills will have some negative impact on your career. Jump now if you can see any soft landing.

2. If that doesn't work keep your head down: People are going to start looking for people to blame - don't make it easy for them! While escalating concerns up the management chain might be the right thing to do it is both ineffective and risky. Your own manager is unlikely to pass your concerns on up and bypassing him/her will not only make you both look bad but could brand you a 'troublemaker' i.e. the kind of person who can be blamed for undermining the project in the first place etc. This of course also means be professional, put in your hours but no heroics.

3. Plan for an emergency exit on T+1: give yourself some options and do the groundwork for a potential internal or external transfer now. Talk to people; there's no reason to wait for others to decide what to do with you when the project funding gets cut or to get swamped in the inevitable 'stampede' of people migrating away in a couple of months.

Apologies if it sounds overly cynical but if you've called it correctly then there is no upside to suffering the unpleasantness coming your way. Be professional, be optimistic but always be realistic.

What impact will this soon-to-be failed project have on your career at the firm, and beyond? In my experience, merely being associated with successful projects is not an indicator of your own personal excellence.

The qualities that you exhibit in the face of adversity and sometimes what looks to be certain failure, often gets noticed by the higher-ups, more so than you think. And I'm talking about beyond your immediate manager.

I personally have experienced seeing my immediate manager get fired for incompetence, and then found myself promoted into his position the very same day. Not pleasant, but it showed that people were watching me, and liked what I did.

Oftentimes, the same chaos and disorganization that comes with a failing project, affords you the opportunity to shine.

So look at the project this way: what opportunity does this failing project afford, for the light to shine on all of my strengths and best qualities? What lessons am I learning from this experience, that will make me a better professional and a better person?

Essentially, the sum of experiences drawn from failures is what fuels true success.

Note: Thomas Owens asked, what specific things a person can do in a project like this. I have a few general suggestions, which I've used as personal guidelines in these situations. Will it help a distress project to miraculously succeed? No - but I've found it has helped me to keep a proper perspective on things, and find personal success in spite of the bad situation.

1) Focus on personal excellence - strive to write ever better code, meet ever higher standards of quality and functionality.

2) Focus on personal metrics - how much code do you write, that spawns subsequent bugs? Reduce that ratio to as low as you can. When asked to provide an estimate for a task assigned to you, are you generally accurate, or do you find that you've over/under buffered the timeline too much? When actually assigned a task, do you provide a good level of feedback on the progression of work, including giving well-and-ahead advance notice of delivery timeline problems?

3) Focus on team metrics - These are just some things off the top of my head: Are other team members lagging because of a dependency on a task you are working on? Are you good at delegating or dividing your task/subtasks to others in the team? Do you find it difficult to communicate with one or more members of the team? All areas that I work on to regularly improve in.

In a situation like this, as the lowest rung of the ladder, there is only so much you can do to help the project.

• Make sure your work is spotless
• help identify the biggest problem areas
• Try to provide answers, not just problems. Look like you are trying to fix them.

Aside from that, you really do have to look after number 1.

• Document everything
• keep all emails, IM conversations
• Try and find a way out of the project if it all possible

Failing projects can be toxic to the soul, cause depression, over work and low self-esteem.

It's all relative to perspective.

I've worked on horrible projects while sitting across from another guy who had a smile on his face every single day. Oh how I wanted to slap that smile off his face.

Some people aren't bothered by the current state of affairs on a project. They enjoy their contribution, their tasks and are working with in the domain of their interestes. While others, have a strong negative reaction to the current state of things. It's all about our perceived expectations for our daily jobs.

While you might be doing some of the work you enjoy. There is clearly elements in the current project you dislike.

You need to identify what those problem elements are, and address them.

• deadline pressure
• quality control
• professionalism
• guidance by management

There are many teams and companies that don't find the above aspects of development important. What I've found is they often think the following.

• Deadline pressure is perceived as way to motivate people.
• Quality costs more and returns limit.
• Professionalism applies to other areas of the business.
• A manager is a timekeeper and not a person who contributes to development.

These problems aren't yours. It's theirs, and you shouldn't waste any energy over their behavior. If you aren't one of the guys who smiles and enjoys his job even as it heads for a cliff, then you should think about finding a place of like minded developers.

You'll be much happier.

Try to be proactive about finding a new way to achieve success for the project. Think about how you can propose some alternatives. Right now your boss is probably getting beat up about the project being a failure, wouldn't (s)he appreciate someone coming in with solutions instead of problems?

Maybe there is a way to split the features into staggered deliverables? There are often degrees of "must have", so see if you can get those prioritized and group them into milestones. Better to have some product at the end of the timeline than nothing. Or consider splitting the team between people working on new functionality and others working on the stability, this way you can show some progress on both fronts.

If these efforts succeed, you will have shown that you are a team member who can find a way to succeed, if not, you will still have demonstrated that you don't give up and will work to find a solution.

Sounds like most projects I've been on. It probably won't end as badly as you think, however:

1) Do your job. Don't worry so much about the overall project as long as you complete your responsibilities.

2) CYA. If the project does fail and you suspect the manager will start blaming everyone but himself, make sure you have enough proof that you did everything required of you (see item 1).

3) Make a few polite suggestions for improvement. Don't sound the warning bells, don't be doom and gloom, just be polite and subtle.

For example, if the team isn't writing effective unit tests (or any tests), write a few unit tests closer to what you would like to see and causally mention how doing so helped you solve a particular problem, or saved you time.

Whatever it ends up being if you want to affect change focus on the positive steps that have concrete results. This project may never turn out to be a winner, but maybe the team can learn for the next one.

Also:

4) Opportunistic refactoring is your friend.

1. Work hard; but not at the expense of your family or your health.
2. Keep a record of all critical design decisions; especially as they pertain to your work.
3. Keep networking, and keep your options open if the situation becomes too difficult or you become a victim of a mass layoff.
4. Try not to think of your project as a "failed project". Everyone likes people who stay positive and fight hard in the face of adversity. So for as long as possible, try to be that person. A positive outlook, grit, and determination are always good for the workplace.
5. If you're anticipating a failed project, then you're anticipating a post-mortem meeting. At the post-mortem meeting, everyone will be held to account. Be prepared to defend all of your code. [Note: As a general rule, you should always write clean code so that it's easy to defend it later.] If you have email or design document that inspired your decisions, then that's even better.
6. At that post-mortem meeting, try to stay positive; and only present your email and design document evidence if your judgement, effort, or workmanship is called into question.

Since your manager knows it will probably fail, you're better off than most. I would consider working with the manager and see if there are any parts/features of the app that can be excluded.

Too often we think every client request is a 'deal killer' and go out of our way to promise the delivery. Until someone works with the client and probes deeper, you may not be able to make these decisions. If you're not able to do this, still try to deliver what you think is most important. Sometimes it's easier to ask for forgiveness than permission.

This is an incredible opportunity for you! Let's take an entrepreneurial viewpoint on this.

Assuming that management wants this project to succeed you are in a great position to help them do so. The reason this realization is so important is because you have to develop the conviction and confidence that the warning signs you're seeing are in fact going to lead to this project's failure[1].

This is your chance to practice important skills in systematic thinking and interpersonal communication. Understand and visualize the issues and potential opportunities that are being missed so you can develop a strategy to communicate these as clearly and simply as possible.

Recognize your opportunity here to improve you skills.

[1] Canceling the project would actually be success. Failure would be spending good money after bad.

Find the problems your project is running into and try to clearly quantify as objectively possible. With every "metric" you quantify make sure you define why you believe this metric is important. You want to give your manager insight into what the consequences would be if a certain metric would not be within "acceptable range". You will need to give some guidelines for each metric to indicate which values are "Good", "Acceptable", "Problematic" or "Bad". Define every criterion up front. If possible you could describe what would be minimally needed for a project to success and contrast this with the current project.

• Static Code Quality can be quantified by lots of static analysis tools. You can keep this as simple or detailed as you see fit. The metrics I suggest you start with:
  • Cyclomatic Complexity
  • Size of your code (eg, Nr of lines per function/class, number of files, number of tables...)
  • Identify which modules are too large
  • Duplication.
  • Adherance to code style
• Defect rate
  • per KLOC by module and or subsystem (identify troublesome parts of your system)
  • you could calculate how much per team member but I think you should keep that for yourself
  • solved vs found
  • time needed to solve a bug (perhaps if this is inclining make a graph of this)
  • perhaps make an estimate of how much time is needed if this keeps going at the current rate
• Planning
  • Extrapolate time used for the features built. Take into account complexity of the feature. This doesn't have to be very precise. What you want to convey with this would be along the lines of "Feature A, B and C are around the same complexity of D, E and F. With features ABC used 170% if the planned time. If nothing changes we expect the same time is needed for DEF" or along the line of "The average feature is taking X% time longer than calculated. We have no reason to assume that the rest of the functionality is easier to build so we should compensate for this in the future planning. It is of no use to have a planning if it is not realistic.
  • Try to have some monthly or preferably even shorter release schedule. If only internal. This could help you further with extrapolating the time you need for the project. This could also save you from making unrealistic commitments (if you don't commit to new work before a release is done). Make a planning for each cylce and sure new features only enter into the next cycle (ie. they can never be added to the current cycle).
• Test coverage: explain the "normal" test coverage values and show how what your current coverage is
• Documentation: How much % is actually documented? How good?
• Modularity:
  • Class based (coupling and cohesion)
  • Package based
  • Subsystem based (how many communication paths are there?)

You should go to work and do what you would do on any project, whether it was succeeding or not. You are being paid to perform your job. Do it to the best of your ability. Assuming you aren't the project manager/lead, it is not your responsibility to decide that a program should be cancelled or not. You deciding to slack is the same as you making the decision to cancel the project. That's not part of your job description.

However, in the bigger picture, that doesn't mean that you should be working 50, 60 or more hours per week to try and meet the schedule. Once again, that's management's job to figure out how to achieve the project objectives. 50+ hour work weeks is not a reasonable option unless they are willing to pay overtime and you are willing to put your family life on hold. Once again, it was management's job to put together an achievable schedule. They can't assume that they can force employees to ignore their family life in order to meet unrealistic schedules.

Also, while the schedule may say 1 1/2 months remaining. That is probably not the "drop dead" date. Some customers may take what you have by that date, even if it isn't all. Some customers may come up with extra funding, since they've already sunk a lot of money into the project. Sometimes the company itself may take on the extra costs to ensure a satisfied customer. All of that is out of your control. Do your job to the best of your ability. That will give management options to work with that could turn a disaster project into a great success story. I've seen it happen many times.

I can only reiterate what others have said, but I emphatically emphasize: Always strive for your best work and keep a paper trail. for both CYA and technical reasons.

Any fall out coming your way depends on managements' personal character; but let me tell you it's hell being on the receiving end of incompetent, lying management. But the very worst you'll leave with your self (and peer) respect intact.

Keep good notes of technical aspects of your Death March. When you get the inevitable interview question have you been on a failed project; why did it fail and what did you do to try to prevent it? Bonehead management is not an answer - even if it is the reason.

It may be an easy way out to assume that it is an inevitable and utter failure and just give up on the project. As a consultant I am often invited to help with the projects that are in various stages of degeneration, failed or failing and part of what I am being paid for is reviving and completing such projects.

What you view as a complete failure, may not be perceived as such by everyone, depending on the perspective. In an ideal world, every feature would complete, coded elegantly and independently of other systems and every line of code tested. I haven't seen a single, project that looked like that in rev 1. In real world, shipping a project means taking some compromises, maybe even missing some key features but the product can ship and even though it will be beta quality at best, at least you'll get the feedback on which things to fix first. The upside of this is that it may inform the management that software is never done and rather than trying to develop a certain v 1.0 in vacuum it is better to iterate and respond to changes in an agile way. Finally for you as a developer in this position, I think the key thing is to develop as good code as possible in these conditions - document it, write tests yourself, if you have to (especially for external dependencies) and use your knowledge of the system to communicate which features are truly crucial and must-have and which ones can wait a week or a month. Make yourself vocal about your concerns and justify them as you did to us. Rather than prepping for plan B, prepare for the fact that you and other poor souls will probably be fixing all that buggy and not done code yet AFTER the product has shipped - as stated above this means writing your code in a modular decoupled fashion - if you think that the persistence layer code is bad, hopefully you should be able to replace it completely in the next revision. Finally, don't despair - dealing with such situation is part of what you're being paid for and it's a learning process. Regardless of the outcome in this particular project, this will count as a valuable experience in the future.