Ask HN: How do you handle highly unrealistic deadlines? - antfarm
======
jklein11
Make a list of the tasks being asked of you.

Add an estimate of the number of hours you think those tasks will take( try to
be as honest as possible, don't try to inflate them or keep them low to try to
hit a date).

Share that with your manager or whomever is imposing the unrealistic
deadlines.

Ask them to help you prioritize these tasks. Show them where you think you
will be by the deadline they set, and how much longer you think it will take.

------
PaulHoule
Just say no.

Ok, it's a little more complex than that. In project management people talk
about the "triple constraints" of budget, time, and scope.

The relationship between budget and time is not a simple tradeoff. To some
extent you can accelerate a software project by increasing the budget, but
that extent is limited, maybe you can accelerate the schedule by 30% relative
to a "least cost" plan.

Fred Brooks learned these limitations the hard way in the 1960s and he wrote
the Mythical Man Month so you don't have to! One problem is that if you add
more people to a project, it takes time and attention to onboard them that
could otherwise be used to get the project done.

A counter to that is that sometimes buying hardware, software, or services,
can greatly accelerate the project. For instance if you are training neural
networks on a MacBook, it is probably worth every penny to get a real desktop
PC and put a 1080Ti graphics card in it, or to spend some money on cloud
computing.

Many managers look at the cost as a function of the deadline, that is, they
see the cost of the project as a function of the time you are tied up doing
it, so if they can compress the deadline, the cost goes down. (or so they
think).

Thus that leads to the "phony deadline" which has no real basis. One problem
is that setting out without a realistic plan you are likely to make mistakes
which will draw out the project, add to costs, possibly make the project fail.

Most of what I say above is laid out in more detail here:

[https://www.amazon.com/Rapid-Development-Taming-Software-
Sch...](https://www.amazon.com/Rapid-Development-Taming-Software-
Schedules/dp/1556159005)

The flip side of that is the hard deadline, where the job might as well not be
done if it is not done on time, for instance, you need to get a grant
application in on before a certain day, or you are putting together a demo you
are going to show at a trade show on a particular date.

It is important to understand what the actual nature of deadlines that you are
up against, what flexibility you have, what impact being late has on the
business, etc.

That leaves "scope" as an area with wriggle room. Probably there are some
features of the project can be dropped or modified, and management may be able
to hit the deadline by dropping features it can afford to drop. This is one
big advantage of "agile" methods; if you have something that sorta-kind works
at the 25% mark of the project and then you hit the deadline with the most
important 80% part of the functionality you are doing better than most people.

