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.
This post was originally published on blog.professorbeekums.com
Top comments (8)
I've worked for consultancies where death marches were effectively the standard - sometimes the project would start and you were already weeks behind schedule. I completely echo this sentiment - quality can not understated, and it's the first thing out the window when you force overtime of a project team.
A tangental point is the idea of the "release windows" - working on Government projects where cloud isn't an option, having to be up at 2 or 3 in the morning to help support deployment and be available for hot fixing etc., doesn't actually produce anything but stress and a sleepless night.
Learnt my lessons - when I see these characteristics, I run away. Fast.
Thanks for sharing your experiences!
I can understand the need for release windows. Sometimes people need to be on hand at inconvenient times. But these times should always be preceded (and followed up on) with time off so that people can rest.
Actually, this is the point. I'm in a death march now - that's not necessarily the problem itself, but the fact that the managers don't understand that you don't give 200% for 3 days (or longer) in a row to hit a milestone, then you just go back to the normal 100% performance after, but you drop to 10% or so, and if you're not given rest, you'll be there in the office, staring at code, but without much use. So the project slips again, leading up to yet another death march. This is especially true with projects with only a few developers on it who are hard to replace, so if they're not available, the whole project stops. Which is true in our case and it's unacceptable for the management, so they just keep pushing for the impossible, given it's better to push in house, than pushing back on the investor/customer.
And lets not forget, any delayed project just needs more meetings, preferably a few hours long per day, so the developers are reminded repeatedly what they should do. Also, how they should do it, preferably by external consultants, or nontechnical people. That increases productivity and motivation for sure. ...
I knew someone in management consulting whose job was basically to lead death marches. That's the situation companies found themselves in where they would reach for these consultancies in the first place. The devs were 100% H1B Visa-holders who had no option to leave the company without having to leave the USA, so they were treated like absolute garbage. This person also had this job fresh out of college with zero technical training in software and had to figure out things as they went.
Needless to say, nothing good was ever shipped and nobody was happy.
Ah man, can't tell you how much I understand you.. Most projects in a company I used to work for, were late from the start.. our crazy PM would have meetings with the clients at crazy hours.. 11pm, midnight.. because we were in "City that never sleeps" but she promised crazy deadlines..
And was later mad when lots of bugs and stuff came up in the QA process.. we would deliberately leave some stuff for the QA process so we could say we were "done" in time..
It just leaves to stressed out devs and bad code
All of this. My last gig was a couple years of a long project leading to a death march. I missed the first death march, since I was on a different piece of the project that wasn't deploying, and had a newborn at home. Against all odds, they deployed something on time.
Where I got hit is Death March II: Production Support from Hell. When I agreed to be the lead on keeping this thing running in production, I inherited some devs. who'd been just rolling off the death march, as they were the experts, and had to ask these poor guys to now help me support a (surprise surprise) buggy system that now had serious production implications riding on it (in one case -- the company was going to lose a major industry certification due to a longstanding bug not sending notifications externally). Not their fault it had bugs -- due to all the reasons you mention above, in addition to the usual "bugs" that are really the users not having tested enough or hitting edge cases nobody had thought about after go live.
It was too much for me, and I knew better than working in this environment, so I left with no job prospects in sight. Those two death marches combined left a lot of bad morale in the team, and ultimately, the company lost a senior employee with a lot of project knowledge.
Don't do death marches.
Nice article!
@all: if you have not already, I suggest you take a look at the
Diary of a Death March by @ExceptionNotFound
This is why i quit and write trading bots instead, if your smart enough to code your smart enough to trade the stockmarket,.