Maybe it is different if you're writing Quake, but I guarantee you the 43rd best selling game that year also had programmers "encouraged onwards" by tales of the glory that awaited after the death march.
BTW, if you're curious, Abrash goes into greater depth at the end of his "Black Book of Graphics Programming", which I think is now freely available online.
My only complaint about the book was that the publisher (Coriolis?) included a notice at the front saying that no code samples, algorithms, etc. could be used in any project without their express approval, but most of the algorithms and code were previously published elsewhere.
Doing 3D was pretty cool too - I couldn't do fancy stuff, but I could display and rotate 3D objects, drawing only visible polygons, draw textures and even have simple lighting.
To me it seems weird how kids work these days. I don't know what a pixel shader is for instance.
Thanks for bringing up some nostalgia. A pixel shader is roughly analogous to a hand-optimized texturing routine, except it runs on the GPU.
I don't know what development process they had at ID at the time, but given that it was a Carmack project, I very much doubt it was anything like "any other" software project.
Sometimes the tricks were cool.
In Bungie's Marathon for instance, the map format allowed you to have multiple rooms occupying the same physical 3-d space. Imagine a spiral stair case that doesn't go up or down, you just run around and around this long corridor like a manifold mobius loop. Quite fun in multiplayer maps with radar. Also worth noting that Marathon was the first game that allowed rocket jumping due to being able to look up and down slightly.
Obviously Marathon had nothing on Quake, but it was really a great multiplayer FPS for its day.
Ultima Underworld came out in 1992: http://en.wikipedia.org/wiki/Ultima_Underworld
(1) There tends to be times where having the product ready is much more profitable than other times (holiday season)
(2) It's a lot harder to rev games.
The end result is you often end up on death march slogs. And unfortnately the state of project management is that they're surprisingly hard to avoid.
Part of the reason is human nature. If we honestly schedule everything out and see it will take 12 months, it will take longer. Because at month 8 it will look like we have three weeks of work left -- to everyone but the project manager and a senior dev or two -- who realize that there is still an honest to goodness four months of work left. On paper it doesn't look like four months of work, but it is (especially because a lot of things are fixing bugs to things that you don't know yet are broken).
So what happens is the pace dev starts to slow down. People start taking vacation, or three day weekends. Before you know it, its month 11 and you're further behind than you were at month 8! WTF!?
You can't just ship the game with this quality. Characters disappearing, levels not loading every other time you play them, etc... A web app you could, and just fix it over the next three months. With a game, while you can service it, its a lot harder, and day 1 reviews are super important -- a 70% metacritic score means no one will even care that you serviced it.
I'm not saying death marches are a good thing. But I've seen that in certain industries they do seem harder to avoid.
a) Doesn't know any better
b) Doesn't care enough to change (there are always hungry young fresh graduates to replace those old guys who keep complaining about not seeing their children grow up)
It's partly a process thing, and it's partly a technology thing. I'm researching game testing . Perhaps if we can get game testing to be better, we might end up with better processes, such as how TDD helps other software domains. Same goes for other technologies leading to other better processes.
Lots of really complicated software gets made every day, but only the games industry really uses terms like "crunch time" and "hero" and "oh thanks for finishing Red Dead Redemption after months of crunch time, here's your pink slip ." It has to mature, at some point, I just don't know when that will be.
How hard they are to avoid depends entirely on how good the management is at coming up with excuses for them and at using carrots and sticks, and on how gullible and desperate their developers are.
Try to be employee #1 of a YC startup while being upfront that you work 40 hours a week, period. Not going to happen in many cases. The death march starts on day one in this industry.
How many YC startups would kill to get Steve Jobs to work even 1 hour a week for them as employee #1?
It's all about perceived value and negotiation. If your company values you enough, they will not make you work unreasonable hours. And if a non-workaholic employee values himself enough, he will not agree to work unreasonable hours.
Death marches are definitely a pathology in the computer industry, as they are in the medical field, where residents are forced to work insanely long shifts without sleep. In both cases, people's mental and physical well being is put at risk, the chance of burnout increases, and the quality of the results suffers.
It does not have to be this way. What will it take for management to stop understaffing and overworking their employees? And how long will employees consent to being worked in to an early grave?
Companies pulling this sort of crap is what really makes me wish the computer field had some effective unions that could collectively bargain for reasonable hours for reasonable pay. I know I'd join in a heartbeat.
It doesn't, but it will be. :-)
I worked on bug, almost full time, about a decade ago, for about a month. A single bug. I hadn't anticipated the bug, and didn't plan for it. I've seen teams spend months trying to hit perf targets. It's the type of thing that isn't uncommon in our industry. I'm not sure how you plan for it.
What will it take for management to stop understaffing and overworking their employees?
Many tmies its not understaffing. Again, I've seen teams struggle to hit perf targets. If you doubled the size of the team it wouldn't make their lives much easier. It may even make it worse.
Our industry is one where you are fundamentally solving new problems (because if someone else solved it, you'd use their code).
Now maybe you're saying we need to toss schedules altogether. Things are done when they're done -- and no crunch time. You do it with 40 hours/week for however long it takes. I'd love to see that dream happen to, but I honestly don't think it ever will.
Finishing projects should not require this and anyone who tells you different is your enemy. I mean that.
Enemy? How melodramatic.
Finishing complex multi-year retail projects is never easy. Someone will have to fix those nasty, hard to reproduce crash bugs, find ways to free up another few megs of memory, smooth out those frame rate spikes, etc. It doesn't matter how many politically correct agile practices you follow; you will always be left with critical last minute tasks that are anything but fun and relaxing to complete. You can choose to work on the kinds of projects where this doesn't crop up as much, but games with blockbuster aspirations were never that kind of project.
Shipping crappy, trivial, mundane, or even good software shouldn't require this.
But shipping something that is timeless is absolutely mentally, physically, and emotionally draining.
I think around eleven men died building the Sydney Harbor Bridge. I'm sure many men will die in the next few decades as we start to commercially explore space. Few programmers will die shipping a breakthrough product, but to say it won't require a heroic effort I think is to say it's not a breakthrough product.
It didn't chase Francis Ford Coppola away from film. It was an isolated example of how bad things can get, a living worst-case-scenario. It wasn't "Tuesday at the office."
Are people dying during game production? No. But they're not in experimental spacecraft, and they're not balancing on I-beams hundreds of feet in the air, either. Given the sleep deprivation you hear about in game production, if they were in either of those scenarios? Yeah. Games would probably take more than eleven lives a year.
Also, do you consider the eleven men who died during the Sydney Harbor Bridge heroes? Or guys that got stuck with shitty, dangerous jobs in search of a paycheck, for whose deaths I feel more pity for, than respect? I'm more with the latter. Astronauts, well, that I can kinda get as a "hero". The gang that made Guitar Hero: Van Halen? Not on that level.
Kind of off topic but to answer your question:
If you define hero as someone who puts forth a heroic effort, then sure I would. Does them dying make them heroes? No. Maybe someone was hungover and slipped. But the type of work they were doing I respect.
If you defined hero as a role model, I have no idea of course (didn't know any of them).
Not right away, but abusing your health takes its toll.
No accidents. No injuries. No deaths. Thousands of years of reactor-time.
(At least, I think patio11 is referring to the culture of crunch time. Correct me if I'm wrong!) You probably know that, but, if not, (or for those who don't) here's some reading:
Patio11 responded to Abrash saying near the end of the project there were rough patches and that eventually they all were tired of working on it. No matter how well run a project might be there will always be rough patches and you'll likely be sick of working on it at the end. Quake is a great game, but imagine running the same level or even worse, same portion of a level all day long looking for obscure bugs. Even if you planned for this time, doing this for weeks is going to suck at some point. It's just the nature of working on a long term project and taking it from working to shippable.
There's no reason that kind of work can't also be rewarding. Running a marathon is hard work, not pure fun, yet people find the endeavor rewarding.
Even in a well-run project, there are many factors that are outside the control or reasonable knowledge of the project workers (the unknown unknowns).
There have been many a horror story of long long LONG hours posted on here ranging from RockStar (lost the link) and many others because of a looming deadline with no working benefits for those extra hours.
I've been on fucked projects and projects that shipped industry-leading products. Success doesn't seem to correlate with a well-planned project. Instead it seems to correlate with how bloody-minded the participants are about shipping and moving forward from where they are.
This annoys me, as I used to be quite the process/method evangelist, and of course cynical project managers exploit this.