Five Tips for Surviving Crunch Time

Chris Eargle / Friday, January 9, 2015

The clock is ticking. Your project’s deadline is fast approaching, and completing it on time is nearly impossible. Perhaps extra work was thrown at you at the last minute, or perhaps things took an unexpected turn. Either way, the pressure is on the development team to deliver the goods. You’re in a crunch.

There are many software development methodologies promising to avoid time crunches if done properly. Yet, most of us have been there at some point in time. If you’re in a crunch, here are a few tips to help you return to your normal work life as quickly as possible.

Tip #1: Don’t Add Manpower

Published in 1975, the central theme of the Mythical Man Month is that “adding manpower to a late software project makes it later.” Forty years later, this is still a common mistake. It is likely due to the intuitive notion that adding more people decreases workload by a relative amount, which makes sense if you’re digging a trench.

Building software requires creativity. Even without an official “architect” title, programming requires design, and working on a team requires cognizance of others’ designs. Adding more team members effectively slows down a project as current team members must bring new programmers up to speed.

Exception: When a serious impediment is contributing to a crunch, adding a team member with the appropriate experience may help as long as the new developer is limited to that particular problem during the crunch.

Tip #2: Focus on the Deliverable

Crunch time is not the time to lay the groundwork for future functionality. It is tempting to create the underlying architecture to support both a current and planned feature, but only code what is required to end the crunch.

If necessary, throw a NotImplementedException (e.g. unused interface methods). It may not feel done, but it is for this release.

Exception: If laying the groundwork is the path of least resistance, do it. Your goal is to end the crunch, not to jump through hoops to follow these tips.

Tip #3: No Gold Plating

I know requirements are never perfect. They’re often missing little things like hot keys, tab order, or an appropriate icon. Perhaps they shouldn’t go into such minute details. In my experience, those details cause trouble (a user experience guide would be more appropriate).

If features are not part of the requirements or guidelines, don’t spend time on them. We all want users to have the best experience possible with our products, but every one of those features takes time to build, test, document, and may even require additional end-user training.

If you feel the feature is important despite its exclusion, or you suspect it’s an undocumented expectation, add a change request so it can be properly triaged or scheduled.

Exception: It is not gold plating to leave a system or browser feature in place.

Tip #4: Reject Change Requests

Features should not be added during crunch time, including those as minor as a modification to label text. Even a change that should take five minutes can unexpectedly snowball into a massive amount of work. Instead, schedule the change for a future cycle.

Exception: The change request accompanies a time extension ending the crunch.

Tip #5: You Got This

It’s no accident the project seemed to be moving quickly only to become a grind. The Pareto Principle implies that the last 20% of the project takes 80% of the effort. With few exceptions, I’ve found this to be a good rule to follow.

If completion is simply not possible, the project manager will need to delay or cancel some features. The upside of the Pareto Principle is that your team already implemented the majority of the release’s features.

Exception: It is impossible to reach 100% perfection in all but the most trivial systems. Don’t agree to write a completely bug-free system.


Despite claims to the contrary, developers are human. We need food, sleep, and exercise to function efficiently, and prolonged periods of long work hours can negatively affect our psyche. Due to diminishing returns, crunch time is only effective for short durations.

I hope these tips help when you do find yourself in crunch mode. Please share your own tips and story. And remember: code healthy!

Image Credits

Images used in this article are licensed under Creative Commons and may slightly differ from the original.

Alexander Torrenegra
package! By Beck Gusler
Henry VIII’s Armor by lizzybeans11
Stop by Jeffrey
Say It With Confidence by Pete