Hacker News Reader

Comment by patio11 | Hacker News Reader

Exciting as it was, we hit the same rough patches toward the end as any other software project. I am quite serious when I say that a month before shipping, we were sick to death of working on Quake.

Finishing projects should not require this and anyone who tells you different is your enemy. I mean that.

View on HN

> 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.

My theory is that un-released software is like physical inventory. Keeping inventory is very expensive because the money spent could have been earning interest elsewhere and product sitting in the warehouse becomes gradually obsolete. As you accumulate a great deal of software inventory towards the end of a big project the cost of keeping the inventory, and therefore the pressure to complete the project, naturally increases. Shipping small increments frequently and not keeping much software inventory is the most efficient process if the product design/market allows. (I'm not saying this is always possible or would have been appropriate in this case, just making a comparison.)

In the past I would agree with you but nowadays I've come to the opposite conclusion.

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.

The production of Apocalypse Now was by any account HELL. Far worse than any game development example I can think of. (Well, DNF jokes spring to mind, but at least they essentially built multiple games there. Apocalypse Now wasn't released until two years after it finished shooting.)

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.

/edit: 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.

> Also, do you consider the eleven men who died during the Sydney Harbor Bridge heroes?

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).

"Few programmers will die shipping a breakthrough product,"

Not right away, but abusing your health takes its toll.

Extremely difficult technologies can be developed safely and correctly. The key example is the US Nuclear Naval Reactor Program.

No accidents. No injuries. No deaths. Thousands of years of reactor-time.

I don't think that's true. Shipping is really hard - basically the end result of execution. A perfectly run project can still suck to work on at the end. The problem is that for most people the fun part of working on a project is the discovery phase when you're building something new. The last 20% of squashing bugs and going from "the code is working" to the "code is shippable" is generally not a good time.

I speak from a point of ignorance, I've never worked in the field. That said, if a project requires months of unplanned crunch time, it wasn't perfectly run. And I don't think anyone would say that crunch isn't commonplace.

(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:

http://en.wikipedia.org/wiki/EA_Spouse

http://arstechnica.com/gaming/news/2011/05/the-death-march-t...

I've read those articles when they were written, and have even read the book Death March. Those situation are obviously not how things should be.

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.

This article resonated with me and it has nothing to do with poor management or exploitation or enemies: for some of us starting projects (personal or otherwise) is always a lot easier and more fun than finishing them. Finishing projects can just be hard. And this isn't just within the realm of programming, although there I find it especially true.

I couldn't disagree more. Doing the grungy work of getting a big project ship-ready doesn't automatically mean there's a death march underway. It means you're a team that's disciplined enough, grown-up enough, to focus on the good of the project, as opposed to what's fun.

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.

They may be your enemy in the sense of an employer / worker bargaining situation, but they may also be right.

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).

Okay, this is a bit sad. How would you respond to your employer if he used this "heroic talk"?

Reply on news.ycombinator.com