How should I behave as a developer in a project that's headed for failure?

think about possible outcomes after it will become clear that it failed and think how to adopt to this situation as it's clear already that it won't be easy go

I'd like to hear from anyone who kept a paper trail which was, in fact, used as so intended. I'd also like a show of hands where it was kept to no avail.

I've been on a lot of projects. Where a paper trail seemed warranted, those who came to assign blame had already chosen their targets without consulting with them first.

I've picked up so many of these types of projects, it's sort of become my specialty.

The first thing to do is to ask oneself if it's worth completing the project at all. All stakeholders _will_ have to be ready to make some sacrifices; is it worth it? Also, like others have said, communication is key. If the team can't have open conversations up-front, it may be best to walk. But, if the team can communicate openly and most are on-board for an adventure, then there are things that are possible.

This is also where a team 're-org' may have to happen, unfortunately. At this point, there may be a huge amount of internal tension that's probably slowing things down. This is a very difficult task, but identify those who have become burned-out and/or antagonistic. Sometimes it's better to cut the team down from 5 to maybe 2-3 instead of adding more people. Is there a 2-3 person team that works most effectively together? The others who are 'cut' will have bad feelings about this. If possible (it usually is), get them on part-time contract and affirm that they are important to succeed (they probably are). Let them cool-off and slow down and mediate conversations with them to use their existing knowledge most effectively.

Don't think about the sunk costs. This will just depress you. Instead, think about all that you have (e.g. knowledge, code, documents, connections, relationships) as resources to help you get to a destination.

Redefine the destination. Take an honest inventory of your current state and distance to the destination. Where can you realistically get to, with a best effort? Which promises will have to be broken? Which ones must be kept. This is going to irk some people, so it's going to have to be very calculated. Sometimes this means just finding a way to get the ship to a close port, if only just to refuel.

If there isn't one, stand up an automated test harness with as many tests as possible, in the shortest period of time. If you can find a 3rd-party tool that's easy to set up, use it. But, you may have to write some throwaway code just to get something working. Don't worry if it takes a day or two to get going, it will be worth it. Shoot for broad tests, rather than unit tests, at first.

Divide and conquer; Isolate and build out from the solid parts. Which parts of the system can be hidden behind a black box interface and add value? Which parts of the system are so rotten that they have to be re-written? Slice the system up into pieces and remove the bad ones. Unfortunately, this requires a bit of skill, art, and talent. I most often deal with systems in OO languages. So, it's quite easy to apply a refactoring interface/factory pattern to things. The really rotten parts can even be replaced with mocks for the short-term, if an interface can be defined. Another thing: the Pareto principle. Re-write the 20% of the system that is creating the 80% complexity.

Aim for early, easy wins. Shrink the development cycle. Show some forward progress. That will help revitalize the team and add momentum.

The gut feeling for a lot of people in this type of situation is to 'brute force' it. People get addicted to 'putting out the fires' But, that's completely the wrong path to take. Come up with a new plan. A plan that can be done with everyone working 40 hour weeks. Let some of 'the fires' burn, but contain them. Don't lose hope, and instead use brains.

However, in the end, it is also completely ok to walk away, especially if there's no incentive to continue.

I've had employees try to the "build a better solution" approach behind my back. The big problem with it is that it assumes the person actually has the full picture. In a small project, that may be the case. But often it isn't.

In the case I have in mind, said employee delivered a solution that did in fact do most of what our current solution did very well with little complexity. But it utterly failed to account for the strategies that were in place for future functionality, that placed very different requirements on the platform. As a result his solution was of no value to us.

There was serious discussion about terminating said developer because of the amount of time he'd wasted on that, and the discord it created in the team when he tried to push his "solution" as an alternative to the existing system.

Often the direction is set by managers for good reason: Sharing every bit of detail would paralyse even relatively small organisations.

That's not to say that skunkwork projects like that can't work or be beneficial, but in my experience the odds are high that they will overlook something important. Before doing something like that, the developer should at least put in a lot of effort to try to learn exactly why the current project is the way it is.

Right on. Working conscientiously when easy excuses for doing otherwise are in season is the essence of professionalism. Providing one's best given the circumstances is the core character trait. Deadlines move, budgets expand, requirements shift and staff move on (including managers). All are beyond the line worker's control. Sometimes, life includes a deathmarch. You still gotta' throw strikes when trailing by thirteen in the top of the sixth.