
How should I behave as a developer in a project that's headed for failure? - robin_reala
http://programmers.stackexchange.com/questions/197650/how-should-i-behave-as-a-developer-in-a-project-thats-headed-for-failure
======
edw519
Choose from 2 extreme alternatives:

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.

~~~
Spooky23
So do a death march or quit? Very extreme.

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.

~~~
CodeMage
Maybe it sounds extreme, but I agree with @edw519: you don't want to work at a
place that lets a project fail as badly as the OP described it. I've been in
situations like that too often and I've learned that particular lesson too
well.

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.

~~~
PaulHoule
I think that level of "failure" isn't exceptional in the field.

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.

~~~
loup-vaillant
> _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"._

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.

------
rquirk
Thing is... a lot of projects _seem_ this way when you're in the thick of it,
but towards the end the mess can untangle itself and provide a useful
tool/product for someone.

> 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"?

~~~
zenlikethat
Interesting take, in fact recently I was working on a project that I was
convinced was going to be a huge mess but in the end out clients seemed fairly
happy with it, and understanding on inevitable roadbumps.

> 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?

~~~
rquirk
> 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.

~~~
papsosouid
Have you never worked on a reasonable sized application before? 100 tables is
entirely ordinary and expected.

------
powatom
I was fortunate enough to experience this exact kind of death march over a
period of around 18 months.

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.

~~~
ctdonath
_make sure there is a paper trail_

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

~~~
fr0sty
> 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.

~~~
ctdonath
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.

~~~
shrikant
Having conversations documented in emails really saved my keister on multiple
occasions.

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.)

------
cateye
If you are the only one that is seeing the upcoming failure, this can mean 2
things:

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.

------
codeulike
I found it interesting that his list of reasons why the project might fail
sounds like pretty much every project I ever saw in the 1990s and early 2000s.
Although some of them are definitely bad signs, some are just par for the
course in organisations that arent big on software development. I wouldn't say
its a guaranteed failure. He might just be unfamiliar with what real-world
projects are like in an enterprisey environment.

\- 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.

~~~
nahname
Enterprise software development. Plan, plan, plan, plan, execute, fail,
extend, extend, extend, deliver. The PMs job is to get the project extended
from day 1 because nothing was planned out correctly.

------
larsberg
One other possibility is that this developer is experiencing schedule chicken.
I'd recommend reporting your time estimates to your lead, giving it the old
college try, but going home at reasonable times and not pushing the clock too
hard.

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.

------
eyourdon
One of the implicit assumptions in this thread is that the developer actually
has a choice -- e.g., he can "run the other way" if it's a bad situation.

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

------
Nursie
Be professional. State your concerns to your manager, and probably a level up
as well. Make it clear that you don't have any confidence in the project as
planned and you think that the cause is a hopeless one.

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.

~~~
sageikosa
The downside to such a strategy might be that the reason for the impending
failure is the manager, and/or the level up as well.

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.

~~~
Nursie
Well yeah, the reason I mentioned the level up is that sometimes your manager
is the problem, and sometimes your manager isn't telling the business about
the problem.

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).

------
kyllo
_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._

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

~~~
patmcguire
Putting an entirely new team on an existing code base is madness.

~~~
kyllo
Yeah, everyone who's actually worked on a software project knows that reading
code is harder than writing it, so just understanding the existing code (which
is almost certainly under-documented and under-tested) will be more than half
the battle.

------
ap22213
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.

~~~
levosmetalo
The guy clearly said he is a developer. While your advice is sound, it is
something that only the manager has authority and responsibility to do. It is
just impossible it almost any organization that a developer can turn project
and project methodologies upside down like suggested here.

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

~~~
ap22213
I don't quite agree. I agree it can be difficult. But, if there's sufficient
respect between the management and developers, then it's totally possible. The
manager wants to succeed, and most are pretty reasonable to ideas, especially
when put into a tight spot.

~~~
levosmetalo
I agree that it's how it should be, but the author of the original question
seemed pretty upset exactly because in this particular case it was not like
that.

------
harryf
In a culture like that appears to be, it's pointless to be that guy screaming
about the upcoming iceberg. No one will listen. Far better to be the guy with
solutions once fail happens.

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.

------
damon_c
I was recently hired to complete a specific task on a project that sounds
similar to this one. On the 2nd day of my involvement and having read through
the code a bit, I realized that the task I was hired to complete was the last
thing they should be worried about given some of the existential issues in the
code and architecture given the deadline.

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.

------
orangethirty
This one hits me straight to the heart. On January of this year I was involved
on a big project. The company needed to have a piece of software written with
their own custom ReST framework. The framework was/is undocumented, and was
still under heavy development. The software I had to build had _some_
requirements, but the actual design was not set in stone. I was given a
"technical document" and told to build it as is. Turns out, the document was
wrong, and did not follow their conventions of even architecture. I talked
with the person in charge and we changed the architecture to have it fit
correctly.

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._

------
martin-adams
Sometimes it's hard communicating the situation to a manager as opening that
pandoras box can end up meaning you spend more time giving status than doing
the actual work.

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.

~~~
euroclydon
If a project is so obviously in bad shape, management should be aware,
otherwise they are incompetent. Therefore there is nothing to be gained by
telling them it's messed up. Typical business time-frames do not allow for an
entire team to start over on a project. Going rouge and creating an
alternative solution is an option if the developer feels strongly that there
is someone in management who will appreciate a better alternative and only
needs a working proof of the idea in order to embrace it, but lacking that
confidence, it's probably a waste of time.

------
mmaunder
I found myself doing consulting work alongside running my startup for a
company called The Point that had this dumbass idea to create a "cause" and if
enough people joined the cause it would reach some kind of tipping point and
the thing would happen. The founder I was reporting to, Andrew, was nice
enough, but I had no faith in the idea. My job was to develop a web based
widget which seemed to have no reason for existing, but I happily did it
anyway and took their money. 3 months later they pivoted, rebranded and today
their market cap is $4.9 Billion.

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.

------
notacoward
They are paying you to do a full-time job, so do a full-time job. No less, no
more, and record your time carefully. Remind people, if necessary, that
retaliatory termination of someone who is fulfilling their employment contract
is illegal. Do what you can to keep that kind of talk from going up the chain
any further than necessary - ideally only to your immediate and somewhat
sympathetic superior.

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.)

------
seivan
Been in one too many of these, it often makes you question wether it's your
fault, and that is very devastating. Though unknown to most people as soon a
project is treated as a project and not your own product, its faith is decided
by someone else.

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.

------
alan_cx
To come at this from a different angle, throw in some random thoughts, play
devils advocate and all that....

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.

------
rikacomet
Approach A: The more stenous one, which requires a lot of willpower, moral,
positive attitude, and undying zeal.. is to point out the mistakes being done,
in a respectable and proper manner on proper stage, where everyone can take it
in a non-hostile way. This approach assumes that the current leadership is not
capable of steering the team out of the wrong path, and since you can see the
problem, you are more than ready to take the baton in your hand.

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.

------
jakejake
The question is interesting but the scenario doesn't sound like that much of a
disaster to me. Maybe I'm the only one here who's worked in the insurance
business though...?!

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.

------
edderly
I would recommend Yourdon's book, "Death March" as mentioned in one of the
answers. Although it feels a little dated it is a well reasoned analysis that
at worst can give you perspective on a bad situation. When I was in a true
Death March project I was surprised that there are so few books on the same
issue.

~~~
GFischer
Nice, I haven't read the book, but I liked Yourdon's book on Structured
Analysis (that was the state of the art being taught when I got my degree !!)

------
jdavid
It sounds like this is a 'Kobiashi Maru' Test, which is a no win situation
that Starfleet gives to it's cadets.

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.

------
pullo
As everyone said, keep a paper trail and update your resume. It would be even
better if you are left out of the finger pointing-' blame circle' on D-day.

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.

------
babebridou
My two cents:

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.

------
LarryMade2
One, own the project, think of what is the best approach - maybe a rewrite...

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.

------
smackay
I'd be hesitant to raise concerns, on what appears to be a relatively small
project, in case you become the scapegoat and a way for either the manager or
your colleagues to point the finger at you for not being a team member and
hence the reason the project failed.

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.

~~~
ctdonath
The rats are first to know what's going to happen because they're deep in the
bowels of the system - dirty, dank, ugly, but know the real story. Looking for
and taking an exit can be the smart move if you know the boat is going to
sink.

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.

~~~
smackay
I completely agree. It is the short timescale that makes toughing it out worth
considering. If the project had several months to go and not just six weeks
then speaking up or getting out would be the correct courses of action. From
the problems described in the OP it seems unlikely any fixes can be applied to
avert disaster.

------
forgotAgain
Plan for the failure. What will things be like when the project fails? How can
you best position yourself in the wake of the failure?

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.

------
Choronzon
Everybody is too focused on the project,the wrong question is being asked
here.It should be "How do I PROTECT myself as a developer in a project that is
heading for failure." All throwing together weekend solutions will do is waste
your private time and put a big target sign on your head,its only worth doing
that if you have a fair chance of solving it and you will get the lions share
of the credit if you pull it off. Look for other roles internally or
externally, protect yourself how you can and emotionally distance yourself
from it. Worry about your career not the stupid project.

------
dirkdk
Dont be a negative force in the team. No technology exist outside of a
business context.

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

------
sillysaurus
_Communicate your concerns in the most concise and non-confrontational way
possible up the management ladder. Summarize the risks, but do not try to
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._

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.

~~~
vidarh
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.

~~~
bjourne
> But it utterly failed to account for the strategies that were in place for
> future functionality, that placed very different requirements on the
> platform.

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.

~~~
vidarh
Did you actually read what I wrote? Including the sentence you quoted?

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.

~~~
bjourne
Do you honestly not see how someone that takes an initiative like that could
be an incredible boon to a company? When you punish people like that, what
you're left with is an office full of drones that does exactly what they are
told, nothing more nothing less.

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.

------
jokoon
I feel that like 90% of the time, programmers don't really trust the project
they're working on, because 90% of those projects are not actually worth a
damn.

------
FollowSteph3
Run around your desk with your arms flailing about screaming then after a few
minutes crawl under your desk and go into the fetal position repeating over
and over its the end of the world.

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.

------
cfesta9
You should treat the project with extra effort. You have 1.5 months to go.
This is what you know. You are signed on to a project. The project at hand
sucks. The inner politics can not be manipulated. With you knowing all of
these factors, maybe there is a way you can change the outcome of the project.
At the least you gain something from this project.

------
SonicSoul
i had a similar problem in my first real programming job. i was hired along
with a very senior person to deliver a project. accept that very senior person
didn't know what he was doing (something that was no immediately obvious to me
since i was very junior).

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.

------
6d0debc071
If it were me, I'd ask for reassurance on my concerns, and if that didn't lead
anywhere I'd start looking for another job.

------
jaredsohn
One thing learned the hard way is that if you are working for a contractor on
a project managed by civil servants (especially where the lead civil servant
used to work for the contractor), "success" isn't necessarily completing the
project on time.

------
Create
Just be aware of the stuff below:

[http://www.ribbonfarm.com/2009/10/07/the-gervais-
principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-
the-office-according-to-the-office/print/)

------
snorkel
You should quit. Clearly you don't enjoy working n this and life is too short.

------
TeaLeaves
Maybe the higher ups want the manager to fail. They've given the manager one
team already which failed and now they've given him another team. The poor dev
is just stuck in the middle of a power play.

------
dschiptsov
Everything that doesn't kill you makes you stronger.)

------
mortdeus
You are pursuing the wrong profession if you think challenging problems and
impossible deadlines are anything less than hackers ecstasy.

~~~
angersock
There's a difference between problems that are challenging because they're
complex puzzles, and problems that are challenging because they're poorly
defined or full of bullshit constraints.

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).

------
ashwinaj
1\. Work to the best of your ability OR 2\. Leave and look for better
opportunities elsewhere

------
krumiro79
work hard, complain hard.

------
yekko
Get the hell out of there, find a better job, always be looking.

------
sigzero
Voice your opinion. Do your work. Look for other opportunities.

------
joepet
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

------
chsonnu
Get some QA engineers to manually test every build.

------
michaelochurch
Honest, "be slightly evil" answer: say absolutely nothing. Just work. Get done
what is asked of you. When you have free time (which you often will, due to
the chaos as things start to shake) use it to build skills for your next gig.

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.

~~~
cateye
With this behaviour probably you will survive this project but in the long
run, you will be wasting your life and maybe miserably unhappy in the end.

~~~
addandsubtract
"Do as you're told" and "Don't talk back" are probably the worst "rules" I've
been taught in US grade school. Following that mentality will net you exactly
this: a miserable and close-minded life.

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.

~~~
gbog
That's not true. Being able to endure and suffer silently is a skill that is
often the way to survive through struggles and win the game in the end. It is
mostly the case for politicians and mafia members, but it is also useful for
developers.

~~~
addandsubtract
Sure, you can play the endure card and just do your job in the hope of one day
pulling ahead of everyone. But what if that isn't the case? What if you
silently work your ass off and then get laid off anyway? If there's one thing
I've learned, it's that you earn what you put in. It's in your interest to
push the product, create a drive in the company and basically make it the best
environment for you and everyone else to work in. And if that is met with nay-
sayers or incompetence, then you should be moving on anyway.

~~~
michaelochurch
I'm not advising anyone to "silently work your ass off" because that doesn't
work either. If you're on a failing project that will harm your career, leave.
But leave silently unless there's a credible chance you can fix it (and
usually, you can't).

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.

------
paulhauggis
I had this issue.

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.

------
yoster
Whatever you do, do not act negative in any way whatsoever. People like to
point the fingers when shit hits the fan. Try to be as positive as possible
about this situation.

------
gwgarry
Also be weary of being blamed for the failure and not being paid.

