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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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,.