a. Treat this project as if it were your sick child on life support.

b. Treat this project as if it were a gazelle being ripped apart by a pride of lions.

If you choose (a), do anything and everything you can to save it. Be open and sincere and stop at nothing.

If you choose (b), prepare a resume and run the other way. No sense risking your own well-being on a lost cause.

The worst thing to do would be to make any choice in between these two.

Unless you're in a tiny company that will literally go out of business if the project isn't complete, there is a valid middle ground: cover your ass to avoid blame, pitch to the PM to get the schedule extended, salvage as much as you can, and move on and do better next time.

In the meantime, take a better job if one turns up. But don't be lured into extreme action by magical thinking. If a failed project is inextricably linked to your personal well-being, you're in the wrong business.

Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointing" and "paper trail". When you find yourself in a situation where that becomes important, it's time to consider leaving and it's always better to leave on your own terms.

Unless you're deeply invested in that project or that company, it's usually better to start looking for a place where projects fail more gracefully than this.

It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B".

"Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables.

"Team B" sometimes delivers the product, usually late. Sometimes it doesn't.

That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.

First: why is that? Are there good reasons for this, and does this happen for those reasons?

Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management.

Whether one should quit of course depends on how wrong.

Taking a better job is fine, but halfway a project it might kill the project when some of the top guys decide to leave. It might even be worse when the architect of the legacy-system decides to leave with knowledge of all the undocumented business rules.

It's so important, that a project is well managed, because a lot of the aspects of building something new are extremely satisfying to work on. However with mismanagement it's easy to demoralize the team.

Exactly. The world is pretty small and you shouldn't step on somebody's toes unless you absolutely don't see another way out.

The sensitive thing to do here, is to make sure you've got your ass covered and if this is a persisting problem or you feel like you can't work there anymore, then you quit after the current job is done. And hopefully you can leave with a good recommendation.

To get high performance without burnout it is necessary to switch from complete engagement to complete disengagement every few hours.

The Serenity Prayer from Alcoholics Anonymous is asking for the right thing here, even if you aren't religious.

"God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference."

It's great to be passionate but it's also important to be detached about things you can't control.

One detail that is missing from this story is the nature of the deadline. Lateness is endemic in software development, and successful projects often get delivered years after they were promised. Late doesn't necessarily mean "failed."

You can't go wrong learning more about project management so you can have a more correct understanding of the situation.

Whatever you do, keep your honor. Being ambiguous about wanting the job gives you the unique freedom to refuse any order that you truly don't want to carry out.

This is fantastic advice, and one of the main things I tried to drill into my team (when I had one), with fairly mixed success. It's very hard to convince people who are attached to a project that they should at any point just go "meh, what can you do?" but sometimes that really is your only option. Advice for any startups in this situation - if you really have to impose some awful condition on your workers, make sure you explain it fully to them. It's easier to accept something you don't like being imposed on you if you understand it, even though you don't agree with the reasoning.

Another really tricky fine line is, having done this a couple of times, to then stop people going "meh, screw it" when they really can control the outcome, but just don't feel like it for whatever reason.

The worst thing about staying to turn things around is that often the failure is set up from the beginning by those in leadership. Your reward for working your ass off to make the project succeed is probably going to be to make someone look good who was responsible for digging the hole that you helped to pull everything out of.

Unless the game board is set up so that you benefit heavily from your hard work (equity, bonuses rewarding the risk and effort) - there's little upside to killing yourself besides some opportunity for personal growth.

Even if one of us calls it right, which is sheer luck with so little information, the OP clearly has most to gain from experience.

That is the only way to learn to correctly identify problems, and perhaps more importantly, what is the best way to deal with for you personally.

But even assuming this, choice (b) is only local optimization. One could consider instead doing (c) - to try as hard as possible to convince the management to shut down that project ASAP, and thus saving the company many man-hours of wasted work. The global gain will be much greater then. Of course if management is stubborn and you're still sure the project will fail, then you're back to option (b).

The severity of the consequences determines what approach is best to take-- and there are many choice in-between working like a mad-man and dropping everything interviewing for a new position.

I would disagree there.

A good manager might take the situation well - they may have been misinformed by others and think things are far better than they are.

If that isn't the case there may be the option of going above the managers head, though this has to be considered very carefully. In may case once it went rather well: the person above me had grossly misreported things above him. We are still dealing with some of the legacy of that period, but getting through it (and that person is no longer here). Of course depending on local politics this could go very badly, so I'll repeat: consider this sort of action very very carefully before taking the step.

In my case saying "things have been X bad for a while, if things don't change either we are going to fail badly very soon or I'm going to burn out inside a couple of months" got the message across (it turns out an honest assessment was appreciated and that not losing some of us through walk out or burn out was important enough to warrant rearranging some plans and expectations). Of course I'm lucky: the Powers That Be here are sensible and I've been here over a decade & proven myself a good few times over so my word carries some weight - a relative new-starter under a less receptive hierarchy would not fair so well.

If there really are no options for plan A for whatever reason, no end of time/overtime will fix the problem and there is no way the management can be made to appreciate the scale of the problem, that leaves plan B: get ready to jump ship.

That being said, decisions like reversing project directions or pivoting are usually huge multi-party decisions not up to a single person (unless it gets escalated to the very very top).

A politically savvy employee would be able to make it work. Albeit, after saving the project (or making an admirable effort that catches everyone's eye), that employee would probably be marked by management for a management role. ;)

a.) If you're sure there's a path to success and you're invested in getting there, do whatever you can to achieve that goal--understanding that one of the possible outcomes is to be told to pack your things and leave. Now. The likelihood of this outcome obviously depends on the exact situation.

b.) Accept that things are not going to end well. Do your job, keep your head down, and start seeking alternatives ex post haste. In some situations, seeking alternatives ex post haste may, in fact, involve fleeing (especially in a short time horizon such as this one) but I've certainly been in situations where the writing was more or less on the wall but more in the vein of a long ponderous collapse.

Fresh gazelle is delicious. Try not to overeat. There's a whole heard, and the pride will catch another one tomorrow. It's all a matter of perspective.

You are the lion and the resources of the company are the gazelle. It's time to feast!

It's really a good time to:

1) ask for a raise for more "effort"

2) ask for more budget

3) that new computer they've been holding out on.

Ya, you can ditch that 17" laptop from 2006. ;) Just ask!

We know that throwing resources into the game this late doesn't work, but it's good to have that extra budget for later just in case you wildly do succeed.

IMHO the best thing to do is to express your concerns and from there on just do your job without investing any extra effort. You can't be reluctant cause this will be received as not caring, neither invest the extra effort because usually the reason projects fail is not incompetent programmers but wrong specifications. Let someone else take the blame.

On the other hand, it sounds like a depressing situation to be in, so I'd prefer your option (b).

> Application is unstable and very difficult to use.

Could be that there are a couple of "killer bugs", fix them and it might not seem so bad. Difficult to use is also subjective, people get use to stuff.

> System is very convoluted, code very hard to understand, very difficult to change.

This could be "I don't understand the code, or know how to change it".

> Datamodel is too driven by a complex relational database (100+ tables).

OK, this one I can't defend :-P

> Unclear leadership, the manager responds to every new information with significant change in plans.

Well, if the plans are adding new features, these should go to the "nice to have" list. If it's "we need to rewrite this" then that's not good.

> Almost no automated tests or unit test.

No autowhatnow? :-D I don't think a project is necessarily "headed for failure" just because there are no automated/unit tests.

> Heavily depends on other systems, but no integration tests yet.

Yet! That's good, there's still time to test this before shipping.

> In fact, we actually just inherited this project (along with the mess) around 1-2 month ago from another dev team under the same manager, who have worked on it for a few month.

Aha! The root of the problem "I don't feel comfortable with other people's code"?

> OK, this one I can't defend :-P

I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?

Maybe it's my lack of imagination, but I can't think how you'd create a design with hundreds of tables by hand - it would surely involve generating tables from some other source. For different types of data I'd lean more for a javascripty-style meta-table with key-values, since I bet all that different type of data wouldn't lend itself well to relations.

What? That is the one thing that stands out as being an obvious "this person has no idea what they are doing" red flag. It doesn't need defended. Having 100 tables is not a problem, in any way. Thinking that having a correct database is bad speaks very poorly for the quality of the developer in question.

Unless you have the authority to guide the project back on track, there are only so many options available to you:

1: Document your concerns and any problems you've identified. Be objective wherever possible (i.e don't bitch about your co-workers even if the reason the project is failing is because they're fucking it up). Any problems that you've spotted and are worried about, WRITE THEM DOWN and email them to your project manager.

2: Keep a cool head. This is incredibly difficult once endless frustration sets in. Bite your tongue, and don't get personal. You will probably fail from time to time, because knowing that you're going to fail is a horrible, insomnia-inducing feeling, and your patience will almost certainly be tested.

3: Offer solutions. If you think a particular decision is to blame for some aspect of the failure, then document it, what went wrong, and what any alternatives may be.

Unfortunately, in my experience and from what I gather from other people, these kind of things tend to come along with ridiculous company politics and emotions. If your gut feeling is that it's going to fail, then your best approach is to try to raise the alarm as soon as you notice. You may be ignored or brushed aside, but you must document everything you do. Don't raise the concerns in conversation, make sure there is a paper trail.

In my own case, the project failures ultimately led to me and several other developers abandoning the company. The project could have been saved if our concerns were taken into consideration and acted on. We even presented a proof of concept redesign which solved all of the existing problems AND presented new opportunities for growth, and were told that our new design would not see the light of day. Keep in mind that we had working code, schemas, deployment plans, addressed scalability concerns, and even had a development roadmap for the new design. Some battles are un-winnable.

I'm in a similar situation and the pressure is mostly caused by a lack of management.

I've been appointed project leader halfway the project and I did my homework by reading the Software Project Survival Guide. We are also supposed to work in a scrum system, but on going business causes scrum to be just an extensive time management tool.

We're nearing the deadline and a few things I picked up are:

1) You need to have a hands on approach and come up with solutions yourself. Show a lot of initiative.

2) Have clear roles of who needs to do what.

3) Don't change roles halfway a project, it only causes confusion and someone needs to clean up the mess.

4) Be frank to your business owner about the current reality . You don't want to be the guy, who didn't say anything and pass the deadline. And don't wait too long with saying it.

5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.

6) Don't fight with the external guys, even if they are trying to run the show. If they start pressing for decisions (framework/system/etc) without a good reason, other than their own comfort, be warned... Get ready for a sticky situation. If you can, stick together with your current team to have some counterbalance.

This, unfortunately, seems to be a rather large factor when it comes to figuring out why a project failed. Unrealistic expectations are absolute killers.

Unless the situation results in criminal prosecution, when the time comes to use that paper trail nobody will care about it.

I disagree. If the company in question is large enough having documentation that you were actively trying to avoid disaster, were competent enough to raise concerns and suggest solutions, etc. can be helpful when people come trying to assign blame after the fact.

If the company as a whole will survive the impending train wreck then having evidence of competence, however meager, is certainly useful in many situations short of criminal prosecution.

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.

Admittedly on one of those occasions, the effect wasn't immediate -- the manager in question basically rage-quit the conversation. But she put a lot more thought into getting confrontational in future disputes.

(Although I have to clarify that this was a fairly dysfunctional environment (and had been for a while), due to which I figured getting things in writing was the safest choice. In future more cohesive settings, I didn't bother with this as much, as the teams tended to have more integrity.)

That's true. Pointing to your paper trail when the shit hits the fan might actually label you as being uncooperative during a critical project; most likely, the manager doing any personnel "cleanup" will be the same that was responsible during the project (line manager vs. project manager). Besides, if a project is doomed, you are not the only one to notice it, so the fact that you pointed it out does not single you out as especially perceptive.

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.

- deadline approaching many of the must-have features are not finished.

- Application is unstable and very difficult to use.

- System is very convoluted, code very hard to understand, very difficult to change.

- complex relational database (100+ tables).

- Unclear leadership, the manager responds to every new information with significant change in plans.

- Almost no automated tests or unit test.

- Heavily depends on other systems, but no integration tests yet.

Perhaps upper management will fudge and extend the deadline (rather than be embarrassed) and the project will limp towards some sort of closure that everyone can just about accept.

In some large organizations (I've seen this previously where I worked), the first group to claim that the schedule was unreasonable became the scapegoat for slashing of features. So, everybody would look around and try to get a sense of who was furthest beyond making it and not say anything unless their team was the long pole, since you'd "benefit" from the increased schedule time anyway without the high-visibility hit for failing to deliver.

Yes, totally dysfunctional. But, in some orgs, it may be the most realistic (or at least typical) way to save the scope of the project.

That's likely to be true for developers in the early stage of their career, especially if they don't have a lot of financial obligations (mortgage, spouse, children, etc). And it helps to have a resume and current technical skills that might be attractive to some alternative employer.

But I run into a lot of situations where the developer is "trapped" by his/her circumstances -- including the current situation of a lousy economy in which there are few, if any, alternative jobs available. So for many, the relevant question is: what do you do if you're stuck in a death-march project, and don't have the freedom to walk away and get a better job somewhere else?

Ed Yourdon

Then (assuming you want to keep working there, as the author seems to) make it clear that if they still want to go ahead then you are fully committed to helping them to the best of your abilities.

But a project in as bad a state as described? Get another job.

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.

If both of those are part of the problem (don't worry! All is well!), rather than realistic (we know there are serious problems here but we think there's a chance/we'd like to try anyway), then it's time to think about the systemic problems and consider finding yourself a new job (IMHO).

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.

That seems like a serious red flag to me. That manager's career is probably headed nowhere fast...

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.

The only thing I'd quibble with is this:

Don't think about the sunk costs.

... not because I think it's bad advice (it isn't), but because if you're a developer it doesn't really matter what you think about the sunk costs. What matters is what management thinks about them. And even though management are supposed to be the numbers people, it can be very, very hard to get them to understand the Econ 101 concept that holding on to bad stuff that's already paid for can cost them more in the long run.

This seems silly, but a lot of the time it just comes down to office politics: someone in management is/was a champion of the project, and a rival in management opposed it, and abandoning sunk costs will give political ammunition to the opponent (who can claim that the champion wasted company money). So the champion becomes irrationally unwilling to let go of parts of the project that clearly aren't working, just to avoid the appearance of "conceding defeat."

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

Which mean you could change all of this, by winning over the team - and not missing deadlines worse than you were before....

It would be nice to learn from the experience of others rather than having to learn on your own each time.

Maybe this is something to talk about at FAILCON?

> Sometimes it's better to cut the team down from 5 to maybe 2-3 instead of adding more people

Tried and true.

> If there isn't one, stand up an automated test harness with as many tests as possible

What do you think about adding on another developer to just do testing? What about a full-time QA person, so that you don't have to build automated tests?

I guess I've never thought about it because I'd imagined that it'd be such a niche skill that it would be difficult to build a consulting practice around it. People are always looking to build new things. But, they're maybe not as welcoming to talk about their failing projects.

Anyway, I have probably (inadvertently) turned around a good 12-15 projects that way. So, I definitely have results. But, the results aren't typically super pretty. That is, it gets people to the next step, to the next set of funding, to the horizon, at least. Some of these projects and companies that I've helped have been sold, and resold, because of these types of efforts, though.

As for adding a developer to the testing role - it is an interesting idea; I've never tried it. Typically, at this point people are scraping the bottom of what they have left to spend. So, it may be a hard sell. I could try it.

Frankly this sounds like the sort of environment where introducing scrum would be a big step forward. As the developer, knowing a good scrum consultant to introduce to the company might be a good move, once the fail happens.

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.

But the client was asking for ridiculous terms. They were using Python/Gevent to handlea lot of connections at the same time. They had already achieved 3K connectionns in testing, and wanted my software to handle 30K per second. Ten times what they had achieved, in two months. Yeah right!

I knew the writing was on the wall. But out of loyalty I decided to stay. I got fucked when the project was cancelled, because I wasn't paid for a months work. I really didnt pursue it because I just wanted to move on from it. And was in a good enough financial situation where that money really wouldnt make a big difference. I did learn a lot from it, and will now cancel a project if it shows signs of too much drama. There is nothing to gain in sacrificing yourself for others who dont appreciate it.

The team who hired me? They tried to blame it on me. But their company is so fucked up that they were even the focus of a mayor PR incident during the past months. So much about being a great company to work for.

But not communicating is not going to help anyone, unless you feel confident that you can get the project back into shape.

So the deadline is missed. It happens. The stakeholders need to be prepared and they need to have runway to take action. Finding out in the final week then being asked to train up 10 new contractors is not going to work. Managers know that it doesn't work, but more often than not they feel that is the easiest way to help.

You shouldn't give up your personal time unless you feel there is some reward, otherwise you will just feel bitter and leave the company in the next crisis. I gave up a lot of personal time to save a project. I did it for my own credibility and passion, but money, time off in lieu and promotion are the rewards that keep employees. I got one week off (after giving 5 weeks of personal time), and £250 of vouchers (but only if during this crisis, I worked a Saturday on someone elses project). I left that job within 12 months.

If anything else, you'll learn the experience of what works and does during crunch time.

1.5 months is nothing. You probably don't have all the data. Be a big boy, stick it out, do a great job and then politely and professionally move on to your next gig.

In "extra" time, start Plan B. Find the parts of the code that might be usable for another project (possibly this one's successor). Make sure their interfaces and dependencies make that easier - which is good software engineering anyway, and can be justified as such if you don't want to explain the real reason. That way you and your employer will both be able to extract maximum benefit from the project when it does fail, helping you both to survive the aftermath.

You will be criticized for not committing enough to the project. You might even be blamed for its failure. It's very unlikely that you'll ever get any credit for helping the phoenix rise from the ashes. That sucks, but it's a bad situation all around and you have a duty to try if that's what you think is best for the company in the long term.

(P.S. To be perfectly honest, I'd already be out of there if I felt that way about a project, but that's the sort of advice the OP was explicitly not seeking.)

You have no input on the stories, estimation and design decision. It's faith is no longer in your hands. They pull the wires, they decide. Hopefully their decision will be good and you'll do fine.

What is the definition of "fail"? Maybe, given that the project is a hand me down, just barely working is good enough to the client. Maybe there is accepted scope for an over run.

How do you know it will fail? Given my questioning of what a fail is, clearly knowing it will fail is up for grabs.

Will the OP's negativity cause it to fail? This bothers me. An employee who is dooming a project is in danger of dragging the whole thing down.

Perhaps the OP is prejudging things too much?

If the OP "knows" it will fail, the likely hood is that so does every one else.

What seems odd to me is the OP's seemingly isolated position, where it looks like he doesn't get to talk to his co-workers or management. If he knows it will fail, then surely so do his co-workers. Management must also know its not progressing. But, he seems unable to discuss this with any of them, even casually. If this is the case, then my concern would be for the future of the whole company.

Approach B: Stay back, perform at 110% but not 120%, if asked, then give your opinion on mistakes being done, do what is your duty, but don't go '"way" out of your way'. Since people might become hostile to you, and don't care if the ship lives or dies. This requires a cold heart, professional and non-positive. But we have to do this a lot of times, due to the behavior mismatch between co-workers. Sounds bad, but deal with it! That's how it is.

A 5-person project with 2 months of work plus another 1.5 months to go is not really that big. Maybe at a startup that's betting the whole company. At a large corp that can just be written off. If the deadline is missed, it just gets re-scheduled. This is not a freak-out scenario. The only concern I'd have is letting people know ASAP if you think the deadline is slipping.

The other stuff about 100's of tables, no unit tests, other system integrations, etc. that sounds like every project in an old school large corp.

In a large corp, as crappy as these apps are, they can go into use internally and process billions of dollars even though they're crappy to use. You then spend the next 10 years improving it.

After this project you will have 5 developers, and several managers that will go on to other projects. I'd say half of those people know what you know, and no one knows how to fix it. If you just work hard on the project one of those developers or managers in years to come might come looking for you to join them on an endeavor. Other than school, I think this is how people develop trust in each other.

If you choose to stay or go, either way you'll build character. It's up to you to decide if you are the sort that digs in and runs to the fire, or the sort that flees to live another day. NOTE: not everyone succeeds that runs towards the fire, but some do, and some consider them heros. Other's consider them fools.

The project might be doomed to fail but there will be individual tasks that can be completed successfully. Complete these tasks (and your tasks) and present them as your contributions to the win/progress column. If you are one of the few engineers who is getting stuff done, you will be noticed in positive light and it will be harder to throw you under the bus.

you cannot stop the inevitable failure of a project, but no where does it say you have to walk towards it. Complete your tasks and just a little more. publicize your minor achievements, and stay out of the politics. this way you can do what is right and remain unscathed when all falls down. Good luck.

Ask for proper priorization and focus on completing as many features as possible, one after the other. It's far easier to build one feature while maintaining multiple others than to build multiple features at the same time, especially with a lot of legacy code.

If they can't prioritize at this point, insist. Point out that in this situation where everyone is stressed for all the possible reasons, with proper priorization you're far, far more efficient than without. For all you know, you can be done with individual parts within hours if you can safely scratch other, less important features that are also in development, only to take them back up and running the next day as they become in turn the highest priority.

If they still can't prioritize at this point, prioritize yourself.

If you don't know it already, find a customer relationship contact and ask for one of the main timesinks for the users that the product is supposed to solve. Let him describe to you the usecase, or let him point it out to you in the functional specs, and do it from start to finish. This one has to work, and that's your new goal in life. Be proud when it's completed, your grunt work is done. Show it to your boss, and let him know that's what requires integration testing right now. Your new goal in life now, is to make sure that this usecase is viable in production. You will find new issues, encounter new problems, but these are better problems because they are not entirely up to your team, they are the kind of problems that a lot more people can understand since they are not purely dev issues. You will get a ton more help at this point, a ton more understanding, a ton more visibility on the project, and management will be able to make a much more informed decision about the so-called deadline.

The key to proper "failing" of a project is to never let it be a complete failure. Finish a usecase and deliver it, so that at least someone could get added value from what the project committed. This is how the customer & management should prioritize for you: make sure that there are usecases where the product is fully functional from start to finish.

Fess up, let them know what is wrong (since you aren't the one that created the mess, offer to be the one than can fix it... if you can do...). Do triage examples on what is there, offer solutions to potential problem points, give examples of a more perfect world. Make sure to point out things that worked good ideas (you are going to hurt feelings, but never tell them the whole concept was idiotic. Show there was good effort and value created in the current system - probably the analysis was spot on, and that's when a lot of the problems were realized and now it needs a rework.

An excuse wont look good on a resume.

Since it's only 6 weeks to the deadline it is probably worth pitching in and trying to make it work. If failure is going to be a big deal then you'll all be looking for jobs anyway. Alternatively it might turn out that the deadline was not so crucial and you will be able to sort out the mess.

Always remember that rats are first to desert a sinking ship - you don't want to end up with being labelled as such.

Being upset at being labeled a "rat" means you're alive.

This pervasive "don't raise concerns or you'll get targeted" is all too often WHY projects fail: people keep telling the decision makers "everything is fine, we'll deliver on time" while mumbling "ain't no way this thing's gonna make it" in dark corners, leaving those with the power to do something about it unaware of the problem approaching, and looking for heads to roll when it does. If you're going to be punished for speaking up (objectively, professionally) then it's time to get out of a toxic environment.

Take the steps required to see to your own future.

Do not get caught up in owing anything to your manager or your employer. Your manager transferred a failing project to your group. He is more responsible for you having this failure hang over your head than you are.

To your employer you are simply a resource, not a person. Do not give them the loyalty you would give a deserving person. It will not be reciprocated. In a world where all employees are basically extended freelancers, you need to put yourself first.

Failing to plan is planning to fail.

Be proactive, take control: cut the project up in parts and focus on those that you can deliver in time. Ever heard of agile?

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.

These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality.

Complex systems tend to have many written and unwritten requirements that aren't captured in their clones.

Anyway, I would not look at 100+ relational tables as being a bad practice in and of itself. I've worked on plenty of systems of this complexity, and it's really no problem at all if you're systematic. You need to have a machine-readable data dictionary and you can't be writing all your SQL by hand.

Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings.

Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation.

For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them.

I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.

Maybe I've been lucky, but in nearly a decade of technology work I have never been penalized for 'overstepping my bounds' by improving something important. I think improving important things is within everyone's bounds, tbh.

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.

In other words, he pissed management off. He busted his as off trying to improve the product and was rewarded by being treated like shit. It really sounds more like he was railroaded by company politics by stepping on the wrong peoples toes.

He busted his ass to deliver something un-asked for that didn't meet more than maybe 5% of our requirements and didn't improve the product in any way, rather than doing the job he was paid to do, because he decided he knew a better solution without knowing or understanding what the full requirements were.

Had he come to me and asked if he could do an experiment to see if he could rebuild part of the system simpler, we would have discussed the idea with him. If he gave me reason to believe he could meet the full requirements rather than what he thought the requirements were, we would certainly have entertained the idea of giving him time to prototype something.

But he didn't. He made a ton of assumptions that were mostly wrong about what the system needed to do, because he was not privy to e.g. the strategy discussions the board and executive team had, and the discussions we'd had with investors.

That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots. While doubtless sometimes they are, a lot of the time they simply have more information than you.

The situation you're describing is a management failure of epic proportions. Failed to communicate future planned features to dev team. Failed to exploit someones willingness to take responsibility. Failed to get input from the programmers (obviously at least one of them thought the code base was a mess).

Oh, and hiring someone who believed making a good product was more important than following chain of command. Big mistake there.

> That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots.

Even construction workers always knows what they are working on and why their work is important. If management is unable to communicate to the developers what purpose their work serves to the company then that is incompetent beyond belief.

In one memorable case, the developer missed some pretty important requirements that mattered a lot to management but did not matter to him. The developer certainly felt that he was railroaded by politics. But I, as an independent observer at the same level, could easily see that management was right to want what they wanted, and that the developer was too emotionally invested to see what he was missing.

Same company, same team, same developer, a different project, not too long earlier. He went off and developed something that really did meet the needs we had, and got rewarded for it. The difference is that he actually understood the requirements and nailed them.

Drive, ambition, technical chops, and an unwillingness to listen first can get a lot done, very quickly. The same characteristics can create a lot of conflict very quickly as well. It is hit or miss which happens in any particular case. And on the misses, management is easy to blame but they are not really to blame.

No, he wasted valuable time and company resources attempting to do something that wasn't needed, or asked for, and provided no value (arguably negative value) to his team in doing so. Of course people work hard and aren't rewarded for it, but it sounds like it's the case here that this cowboy was trying to outwit the system and ended up hurting the team a lot with his irresponsibility.

Also, its possible you pick a stack that causes all kinds of re-training, contracts to die, systems to redo, that doesn't scale to the number of production users, has other unexpected costs, etc. maybe the code is written fast but is hard to maintain. Maybe you have vendor agreement. maybe you have client agreements about where the database can be located. Who knows.

Lots of variables. And you can't see this beforehand. Never ever do this without at least some management buy-in. Someone who is on board with you and can help better define the requirements and explain why things are done this way

Sure, if you sat everyone down and gave them a briefing on every aspect of everything it would be a pointless waste of time. However, increasing the ease with which information can be pulled down seems fairly simple. If dependencies being complicated is the reason for management setting direction, that seems like a coms problem, the sort of thing that's perhaps best addressed with a project management software than a human manager.

At some point, especially when dealing with senior developers in a fast moving startup environment, you have to assume you're dealing with reasonably responsible engineers who understands that if something doesn't make sense to them immediately, their first instinct should not be "I can rewrite this component that isn't remotely part of my job in a few weeks, no need to ask anyone", but rather to ask "what am I missing? Please explain this to me".

I've personally come across many cases where something looked trivial to do better, and occasionally I'm right, but I'm also humble enough to go ask the questions before I put aside the work I've been asked to do and go off to rewrite something else.

When I was younger, I would've actually done this. As I got older i learned some things, and one of those things is that 20% of the work will take about 80% of the time. I'm sure he could take a week or two, develop a kick ass demo that demonstrates a working concept... but it won't make the project finish sooner. Rewriting existing code that's hard to work with is essentially defaulting on technical debt. If he skips essential things like writing a proper design doc (documents are a really good way i've learned to communicate with your team, don't skip them!) if he doesn't have good code coverage, then he's simply taking out a new loan.

I can practically guarantee (and the OP strongly implies it) that the problem with this project is not that it is hard to implement, but that its requirements are unspecified.

Rewriting it in a fancy feel-good language changes exactly nothing and should be treated as an act of sabotage, because it is exactly that.

Yes there is: if you can't get it done in 1.5 months having already spent 1.5 months working on it, you're not going to get >3 months of start-over work done in a couple weeks. Never mind the boss freaking out at the thought of you abandoning 1.5 months of work, knowing the remaining time isn't enough left to complete it (yes, he knows) much less start over from scratch using completely different tools.

If you had that kind of alleged ambition and talent you wouldn't be in this mess to start with.

I disagree with the philosophy of your profit distribution. For one, it overstates the value of the first employee and shits over the rest. If the first employee has been at the company ten years and the second nine, it is unlikely that the first employee is twice as valuable as the second employee. For another, I think the elimination of pensions is one of the biggest things wrong with modern corporations.

What I favor is something more like a formalized version of the traditional family farm or business. Everyone gets a share of the business proportional to how much work they put in (years worked, with some minimum to retain your shares after you quit working). Profits are divided among them, and salaries are paid to current workers before profits are calculated.

Also in my experience, many business applications aren't vastly complex, they are simply very big and have to handle many, many special cases. That's not something you can redo in a few weeks, no matter how talented and ambitious you are.

But no seriouly, if you want to stay at the same company after do what you're asked. Don't burn yourself out. If you're in a position to make change then so it. And if not then fire up your résumé ASAP.

I panicked, and since stackexchange was not around back then, i went to IRC with a very similar question. I was basically told to stop blaming my problems on others, shut up and just do the job. Really it was an angry response and made me feel like i was stupid for even bringing it up. so i put my head down, and tried to do what it took (while not getting any guidance for the guy).

the end result was 3 months of wasted time, the guy getting fired (and he did not see it coming a at all). Somehow i managed to keep my job and eventually being the main person supporting that product. The problem was with management of that place, by hiring new people, and not paying attention to daily progress and direction.

http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...

Asking you to empty a dumptruck with a spoon in four minutes, by your reasoning, is hacker ecstasy (and no, you aren't allowed to threaten the operator with the spoon).

People will probably lose jobs. Sometimes that will happen based on seniority and sometimes it's just random. Sometimes, that will happens to the PITAs who spoke up and happened to be right. You don't want to be a PITA. PITAs become blame dumpsters even when they were right, because enough people hate them and no one will defend them. You're not the only one who knows that the project is fucked. Just keep your mouth shut about the fact.

There's something I call the Welch Effect, which is that the people most likely to be laid off are junior/least-established members of macroscopically underperforming teams (who had nothing to do with its underperformance, because they had no power). Managers are sometimes sympathetic to the Welch Effect and will set a "no infanticide" rule, but not if you're a PITA.

Keep your head down, do good work when work is asked of you, and start planning for your next move. Start networking and searching and building skills now, not when you need to.

If you lose your job, don't take it personally. It's not your fault, and if you tell the story in the right way, no one will hold it against you. These things happen to good developers, especially early in the careers, all the time. Most projects fail. It's not like school where something has to be going wrong to fail a course, because only 5-10% get F's. It's probably 50-75% of software projects that fail.

This is probably the most important piece of advice in the whole discussion. Getting all worked up about someone else's responsibility.

Another interesting side issue not explored yet... I believe its a distorting factor that he has semi-privileged information and opinions about his own area of expertise. If he had semi-privileged information and opinions about the supply of packing tape in the shipping department, or the technology level of the forklift battery charger in the warehouse, he'd wisely be advised to stick to casual careful gossip unless its human safety critical, aka just do his job... at work. At home, if certain that the battery charger is going to cause irreparable financial harm, sure, go update that resume... just keep it at home.

One of the tracks of the discussion here and on Stack Exchange is to elevate the situation to a plane requiring moral decisions. And it just ain't so. A line worker does not have fiduciary responsibility, and as you rightly point out, this doesn't entail issues of life safety, public health, or economic exploitation.

It's just normal muddling through.

The biggest hazard to the person posting the question on StackOverflow is erroneously assuming they are the smartest person in the room, or in its most common form, that everyone else is an idiot. Trains are big loud whistling contraptions with bright lights. Unless distracted, few people fail to see and hear them coming.

DO voice your opinion and professional expertise.

DO make recommendations as to how to salvage or improve a project. Not doing so will not get you anywhere.

If the project is doomed to failure, being a PITA means you're more likely to get fired while silently working out a transfer or next gig has only upside.

If you're a developer, you often can help save projects that are failing because they were poorly outsourced, or handed to the wrong team, or technically flawed. You usually can't save projects that are failing because management never really believed in them, or that are caught in crossfire between conflicting factions on the corporate board, or that have never been funded/resourced at the levels required for success.

The last project I worked on was something essential to Lucent's survival as an independent entity. Many of you have heard of sophisticated telephone switches, like the Western Electric (AT&T) then Lucent 5ESS (http://en.wikipedia.org/wiki/5ESS), a really impressive monster that's truly 5 9's reliable (or it genuinely tried to be and by and large made the grade).

The new way of doing this is (or was as of 2001) to split the functions of such a switch into a Media Gateway Controller AKA Call Agent e.g. the Lucent Softswitch, which understands things like billing, and a Media Controller which does the actual work of connecting A to B and converting as needed (e.g. POTS to VoIP). There's even a dual ITU/IETF protocol for communications between the two, Megaco AKA H.248 AKA RFC 2805.

It should be obvious that being able to offer a complete solution was essential for Lucent's future, as conventional switch sales were at least projected to plummet, and my group was part of effort to create the other half the company needed, the Media Controller. Which was a challenging thing, including that true 5 9s reliability requirement (just say no to hard disks, I was among other things the database guy in testing, and the operational database lead and I had to vet and sign off on each other's designs (mine was a data warehouse approach for storing fine grained events generated by the test system, Oracle was real fun for that sort of thing and we had a 106,000 seat license (!) from them, although headcount was going down to 35,000), and I was personally responsible for testing his system).

ADDED: going off the Yourdon Death March chart included in OP comments, this was a "mission impossible" project, high happiness (fun, challenging project), at least a decent chance of success initially (e.g. we were working with the 5ESS people, who taught us a lot of neat stuff about real 5 9s.)

Anyway, at a certain point, completely insanely a company wide headcount cull was applied to this effort, and I'm pretty sure it was sufficient to kill the project (my testing area was gutted, going from "maybe, just maybe we can get this work done in time" to one engineer plus a little outside help, with one manager, a failed programmer so she wasn't of much if any help).

One of the things that really stood out was the layoff of a pretty famous person in the company, a jack of all trades who e.g. had the energy and skill to take the chosen (Linux based) RTOS from the vendor and get it up and running in our environments, kick the tires and minimally validate it, etc. Don't know if he was a PITA like I was in part, but it's hard to imagine he wasn't at least a bit, he was the sort of guy who was in a position to say "This won't work because I just tried it".

The managers flaunted his layoff like a badge of honor, an implicit "If this guy can get fired no one is safe", and blatantly lied about the grounds. They claimed he was "inflexible" about what he'd work on, when it was a very visible matter of written record that he'd very productively work on just about anything. I never even talked to this guy, I just learned of his background and merits from the written progress reports and mention of him in an occasional conference call meeting, he was perhaps the most visible "exceptional" employee in this make or break project.

And yet he was purged.

(As was I, although that was by abuse from an envious boss and may not have even been part of the headcount cull; while I wasn't hardly so visible, I was the only serious software engineer on the testing effort, and there was no way the company could build the new test system without someone of my caliber. And you'll never create a true 5 9s system without serious testing.)

And as many of you know, the bottom line is that Lucent was bought by Alcetel and is a shade of its former self, including Bell Labs, e.g. http://en.wikipedia.org/wiki/Bell_Labs#2000s:

"As of July 2008, however, only four scientists remained in physics basic research, according to a report by the scientific journal Nature.

On August 28, 2008, Alcatel-Lucent announced it was pulling out of basic science, material physics, and semiconductor research, and it will instead focus on more immediately marketable areas, including networking, high-speed electronics, wireless networks, nanotechnology and software."

http://arstechnica.com/tech-policy/2013/05/newegg-nukes-corp...

"Sleazy" is not, I gather, a word that typically used to be associated with Alcatel, and certainly not the pre-breakup AT&T.

If you're going to stay around pick something that you think is the most important function/feature and make sure that it is amazing. There is almost always some smart people around and some new things to learn.

Taking responsibility for things over which you have no authority will make you miserable and crazy. Find out where your authority stretches and make the most of that area leads to amazing developments. I can predict that the education system will continue to suck tomorrow and there isn't much I can do about it but tutoring a few students at my local school can really make a difference in their lives.

I worked very hard to put the project on the right track, but the issue was the person at the very top (my boss) just wound't listen and do things his way every single time.

Twice, I worked for months on new features that we discussed and outlined only to have the project be completely re-designed (and 90% of my work scrapped) because he had a new dream or a vision about how the project should look.

I eventually quit. It's not worth my time, effort, or sleepless nights.