Imagine you’re a manager on a large software project. You’ve got about a month to go before the intended deadline and your team appears to need at least 3 more months before being done. What do you do?

Many come under the temptation to start a so called “death march”. It essentially means having folks work as many hours as possible: nights, weekends, whenever. After all, if a developer can get a certain amount of work done in 40 hours a week, then they should be able to get three times as much done in 120 hours a week right?

Not. Even. Close.

I used to love the idea of working long hours. For some reason I thought it would make me a better developer and a better person. Couldn’t tell you how I got this impression, but it was there. I had romanticized the notion of being the hardest worker possible.

That belief ended on one release in the second year of my career. I had spent 2 days, 14 hours each day, working on this one enhancement for a feature. It was at the tail end of the project and this really needed to get done. I was ecstatic that I made it a day early. It was time to go home and get some sleep.

I reviewed my work the next morning since there was time to make sure things were polished. To my horror, I realized my work was mostly garbage. What worked the previous day was due to luck. The code had a nasty race condition in it. The cause was embedded in the design so it wasn’t going to be an easy fix. The only solution here was to rewrite everything I had done in 28 hours and I only had a day to do it.

I was done in two hours. The new code was better in every way. It was easier to read. It was less likely to have bugs. It ran faster and provided a better user experience. It used none of the work I had done in the previous two days.

Software development isn’t a mindless rote task. It requires critical thinking, careful planning, and no small amount of creativity. Fatigue affects all of those things.

Fatigued developers are going to be focused on doing what it takes to get some rest. That means doing the bare minimum required of them. They don’t speak up if they see a hole in the product requirements. That would only delay rest.

They don’t explore better alternatives to their current implementation approach. That would only delay rest.

They don’t test their code as well either. Finding bugs would only delay rest.

Fatigued developers are focused on what’s in front of them and only what’s in front of them. The quality of their work isn’t a concern. They don’t care about taking on technical debt. They care about getting sleep. This mentality doesn’t benefit the developers. It doesn’t benefit their team. And it certainly doesn’t benefit the users.

Death marches can be avoided though. Good prioritization of work will ensure that the most important things are worked on first. Frequent communication will bring to light when some things are taking much longer than expected. That enables communication about what tasks may need to be cut or may no longer be worth the investment in time. Cutting tasks is almost inevitable when deadlines are fixed.

The most important factor in avoiding death marches is having the will to not treat it as an option. That can be hard. Why cut anything out of the product? Having everything is better than having only some things!

That isn’t the choice available though.

I once knew a 5 person development team that had spent a full 5 days, including the weekend, on a single critical bug. The issue ended up being a single letter was lower case instead of capital. That’s 25 person days spent on something that should have taken less than a minute to fix.

These weren’t bad developers either. They were just tired. They had been crunching for months to make a fixed deadline. Their fatigue made it exponentially more difficult for them to solve the simplest of issues. The end result was this bug prevented them from finishing a bunch of other features that were important for the product. Instead of cutting features ahead of time in an organized manner that prioritized the most important things, features were cut by default when time simply ran out.

The choice to take on a death march or not is not whether you can have everything or only some of the things you want. The choice is whether you want to be able to choose what you want in the product or leave it to chance. Death marches guarantee that the features you end up with are determined by chance.

Avoiding death marches isn’t just an issue about treating employees well. Avoiding death marches is about delivering the best product possible.