How to Meet Unrealistic Software Development Deadlines
Never deliver late, ever again
BOSS: I know we're a long way from delivery, but just HOW long is this feature going to take to build? Give me a ballpark; don't worry, it's not like it'll be set in stone or anything…
ME: Should take me about six weeks barring any issues. This doesn't seem too complex.
BOSS: Six calendar weeks? Wonderful!
(Spoiler, I underestimated…)
Almost all non-trivial engineering projects run into unexpected issues and blockers.
Even if you win the execution lottery, there's a good chance that you've either  underestimated the scope of the project or  overestimated your own ability to push the project forward.
So you're up against an unrealistic deadline. What now?
Breathe. It's not the end of the world.
Speaking from experience, here are a few things you can do to meet your deadline and feel like a star employee.
Put in extra hours
Hopefully, when you gave your initial estimate you were thinking in terms of 40-hour weeks.
It's looking like the project is going to take about 80% more time to deliver? No worries, just work 72-hour weeks (40 x 1.8) instead! After all, the only factor you can control is yourself. As an added bonus, you'll be celebrated as a hero.
Sometimes the deadline will be so tight that you physically don't have enough time to be able to deliver. In that case, you'll need to…
Cut a few corners
I'm sure you've heard of working smart instead of hard? Find some of those tougher tasks and figure out how to do them faster. Here are some examples that come to mind:
- Don't bother with scalability - that task list probably doesn't need to be paginated anyway. You won't have THAT many users at launch and you're in crunch time baby!
- Ditch the code reviews - who has more context about YOUR code than yourself? Inject that stuff straight into y̵o̵u̵r̵ ̵v̵e̵i̵n̵s̵ production.
- Skip the automated testing - unit, functional, integration, blah blah blah. What's the point. We're worried about DELIVERY, not regression. Manual testing is enough; besides, this feature is fresh on our minds.
…you get the point. Don't squander time-saving opportunities by refusing to cut corners.
Let others know that you're on a tight timeline
I genuinely believe that most people want to be helpful to others. One of the best ways to draw out this instinct is to let people know that you're stretched thin; emotion and empathy will handle the rest. Here's what I mean:
- If code reviews are slowing you down, set up a meeting with your reviewers and let them know about your predicament. Teach them your pain. Your reviewers have certainly been in a similar position before and will surely be kind enough to push your changes through without reviewing them - you're on a tight deadline after all!
- Set your Outlook calendar to auto-decline all meeting invites - citing looming deadlines. You don't have time for anyone else during these trying times.
- Tell your friends that you're stressed out of your mind. Who knows, they might even order you a meal - an hour of meal prep could be the difference between making or missing a deadline.
Okay, I'm kidding…though I'll admit some of the above bullets are old acquaintances of mine (cough cough, extra hours, and technical compromises).
If you'll give me another chance, here are some less sarcastic tips that I've found useful when dealing with unrealistic 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  an opportunity for simplification in complex design and  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.
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.
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.
Being straddled with an unrealistic deadline is not a personal failing, nor the end of the world. Navigate the situation with empathy, creativity, resourcefulness, and clear communication rather than resorting to blood, sweat, tears, and questionable shortcuts.
This article was originally published on Medium in the publication Frontend at Scale.