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

Sometimes the problem is that the issues are communicated, but not the severity. So, you might raise that the database is too complex with 100+ tables, but if the manager does not have an intuitive sense for the consequences of that problem, it might not register as a project-destroying issue. That becomes the disconnect later, and when things go pear-shaped, these disconnects become issues of contention.

The worst thing you can do is to raise these issues quietly and just keep trucking, as if you've done your job, and that's that. [wiping hands gesture] If management doesn't realize that the project is headed for disaster, that's on you (and the others on the team).

But, if you're able to convey the severity of these issues clearly and professionally, the conversation might turn to what can get done in the near term that would be valuable. Or, to the point of other commenters, there might be other factors at play, and the manager might want you to keep trucking anyway. In this case, provided you have been clear about the risks and threats, you really have done your job.

As a parting thought, you could also raise an issue around "what type of company" you want to work for. Perhaps if they need to rock out a rough proof of concept with no automated testing (or any testing!), that's one thing, but I wouldn't want to work at a company that doesn't take testing seriously. So perhaps if this is a manic sprint to prove something, we can all get on board with cowboy coding, but once the dust settles, it will take x amount of time to shore up the work with xyz types of tests. If they aren't on board with taking their medicine and putting the right tests in place, then that might be reason to depart even if the proof of concept succeeds.

1) You are wrong and paranoid. The project will be delivered with some hurdles but will not be catastrophic at all. Try to make sure that your concerns are clearly defined. Contrary to most people here advise: don't try to be the nice guy by being subtle. Be polite but be also confronting.

2) You are right and you will not be able to change the situation. In this case, I would choose the easy way and leave for another job. Watch out for the stockholm syndrome: there are other companies where you can enjoy your work. Don't feel to much sympathy for the current situation or be afraid of uncertainties that come with leaving.

I hope future historians will be astonished that all of us chose to accept such insanity without doing anything to change it.

Thought experiment: There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks. The project has been in development for 1.5 months and has 1.5 months to go before the deadline. Their current solution apparently involves relying on a relational database as some kind of programming language or configuration system (100+ tables). There's a good chance that a developer with ambition and talent could singlehandedly deliver a superior solution within a short timeframe.

So what stops the developer from executing? Primarily his own (fully justified) fear of negative consequences. But the only reason his fears are justified are because of structural problems in how companies operate today: managers are expected to drive the direction of the project and are given the authority to do so, and the authority to fire anyone who won't go along with the manager's vision. That makes it impossible for a developer to make sweeping changes and be perceived as doing anything but challenging the manager's authority. But it's not about authority. It's about the customer. It's about making good products. Yet the environment is set up so that the developer concludes that it's entirely justified to be afraid; to sit quietly and do nothing. And it's precisely this collective fear that drives this sort of degeneration within companies.

There has to be something better. I want to try to build something better. Some new way of thinking about how to build a modern software business. Profit sharing, maybe. It might be possible to set up a company such that it could pay its employees a percentage of the profits. The first employee would get 15%. The next employee would get 7.5%, and the next 3.75%, and so on. Then as the company makes profit, that profit is continually paid out proportionally to each employee.

That system has all sorts of flaws, though. One example: an employee should only be getting a percentage of profits while they're at the company. They should be getting their full percentage on day one, and should give up their percentage on the day they leave the company. But I can't think of any mechanism which would actually let a corporation pay out like that. If you tried to pay out profit via dividends, then you'd have to allocate the percentages using stock, and employees don't typically get stock up front on day one -- it takes several years to vest -- and they don't lose it when they leave the company. So profit sharing via dividends wouldn't work.

The idea is to provide an incentive to employees for projects to be useful to customers. There's currently no incentive. Employees are generally expected to play the politics/career game in order to secure a safe future for themselves. I guarantee you that if the employees at OP's company had been given some percentage of future profits, then they would currently be revolting and calling out that manager's behavior and incompetence.

Most organizations operate (and should operate) according to what the top-level decides should happen. If the top-level defaults on that responsibility, then chaos will ensue.

In those cases a value judgment of the process is a value judgment of the organization, and most astute managers realize it sometimes before the "innocent" (i.e., socially naive on organizational dynamics) system builder guy realizes it.

I voiced some of my concerns to the manager of the project. He got upset and defensive. I quit on the spot.

I had never done anything like that before but I'm glad I did. It could have been rescued but that would have taken a huge personal effort on my part that I didn't foresee being appreciated.