How to Meet Unrealistic Software Development Deadlines
Begin with empathy

Start by digging into why this deadline exists. Is a code freeze coming? Is there pressure from up above? Is a competitor trying to beat us to the punch? Did we promise a client? Is this completely arbitrary?

How you treat a deadline should depend on the circumstances. If the deadline is arbitrary then start by speaking up! There’s a good chance that your stakeholders would prefer to under-promise and over-deliver.

Sometimes there IS a good reason for a deadline. Perhaps GDPR is kicking in and this project is necessary for compliance. Maybe your startup loses funding opportunities if you don’t demo in time. In these cases, you might not be able to push the deadline, but you can still…

Provide alternative solutions

There are ten-million-and-one ways to build the same software. Sometimes it may seem that the constraints are too rigid:

The current implementation is legacy and also spaghetti. There’s no way to avoid paying the legacy code tax.

There are no reusable components that can solve our exact customer use-case. We’ll have to roll our own.

We must introduce this complex caching mechanism, some of our customers have a crazy amount of data!

There is almost always [1] an opportunity for simplification in complex design and [2] wiggle room in product requirements provided that the trade-offs are worthwhile.

Is it possible to develop your feature with tech that is easier to use? Perhaps you could set up a facade in front of the legacy system and kick off a much-needed migration as a bonus?

Can you find an existing component that satisfies most of your use-cases and re-purpose it? (e.g. maybe that form field doesn’t really need to be equipped with artificial intelligence…)

Is there a more straightforward implementation that comes with minor tradeoffs? (e.g. releasable to 99.95% of users)

Don’t be afraid to flex your creativity muscles.

Find help

Have you heard of Brooks’ Law? Fred Brooks in The Mythical Man-Month famously asserts that an incremental person, when added to a project, makes it take more, not less time. Obviously, this law has a few caveats and is (in Fred’s own words) an outrageous simplification. The point I’m trying to make is that adding additional resources is not always an effective way to meet deadlines.

That being said, there are times when an extra pair of hands CAN help. Questions to ask yourself include:

Is this person already on-boarded? Do they have experience with the system or tech stack? Do they have enough context?

Are there orthogonal slices of work that could use owners? Is the work parallelizable?

If you think having more people can speed up delivery, make it happen! It’s not a personal failing to ask for help.

Manage expectations

This comes back to the topic of communication, but I feel it’s worth stressing.

The reason that your deadline exists is likely because someone up the food chain expects that you’ll be able to finish this project in a certain amount of time. Unless you’ve got a sadistic boss, chances are they aren’t asking for (what they perceive to be) impossible results.

Speaking up early and often keeps expectations aligned with reality, for all parties involved. Keeping people informed can help distribute the pressure created by a deadline and make it much less personal.

With the right amount of communication, you might find that deadlines inexplicably change; along with the definition of late.
['Bowei Han']
['Soft Skills', 'Technology', 'Software Development', 'Front End Development', 'Software Engineering']