Hacker News Reader

Comment by decode | Hacker News Reader

Just this weekend I watched Machinima.com's documentary series on the history of Valve Software:

http://www.machinima.com/film/view&id=42271

One of the common themes in the series is Valve's frequent choice to delay shipping in order to get things right. Gabe Newell says something like, "Your software is late for a while, but it's bad forever." As far as I can tell, this has worked extremely well for them.

Which makes me wonder what the difference is between Valve's games and Gmail. I think it has something to do with their games being about experiential storytelling, and Gmail is a tool to accomplish tasks. I imagine most software falls somewhere on a spectrum between the "tool" and "experience" endpoints and I wonder if other software besides games might be hurt more than helped by "release early and often."

View on HN

Valve can't afford to release bad stuff and patch it later - a large number of their games are single-player, and lack significant replayability. The first run-through for most players is the only run-through... you can't correct the bad experience later. It's a little bit like how you can't release a bad movie, correct it with a "Director's Cut" later, and expect significant numbers of people to come back and re-watch it.

As for Valve's multiplayer games, they do release often. Team Fortress 2 gets sometimes weekly updates (balancing and bug fixes mostly), with large content releases every few months.

Interesting. I was going to come in here and ask if this advice was good for me to follow as a long-format fiction writer--but you seem to have answered that.

I know you mentioned long-format, but if you are able to serialize your work you can go for the "release often" format.

Shows like 24 actually do not map out the entire upcoming season from head to tail before shooting - and in fact the back half of the season is entirely un-shot when the season begins airing. This allows show runners to tweak the show based on fan response - serializing fiction may have a similar advantage.

The difference is that valve's software has to have a build installed on the client's computer or worse, a disk you shove into a console.

On the web, your releases update 100% of your client base instantly.

Though I do agree that depending on your market, "release early and often" can hurt you. Getting a bad reputation early can be hard to shrug off later.

It's not just the medium. A game with plot and direction won't be the same when replayed. Imagine someone trying to repeat a joke to make it sound funnier, when you've already heard the punch line. So, danger of over-generalisation, but certainly games like TF2 can be improved with updates, extensions rather than revisions.

Perhaps that's his point about bugs vs new features. Releasing often works when you are adding more good bits, not so much when fixing broken bits that should never have been released in the first place.

Yes, one part is the ease of productionizing for the web.

That said, I think there are always techniques for using the early, often, listen approach with private betas, multivariate testing, etc.

Release doesn't necessarily mean releasing to the public, and does not even necessarily mean releasing something user facing.

Another story on valve that I read indicated that they do lots of testing and iterative design in house in the early stages, so they seem to have an internal 'release early, release often' culture, at least as compared to other large game company cultures.

This is also the philosophy @ Pixar - you can't release a movie twice, so it had better be right the first time. You achieve this by having 1000's of internal reviews, checkpoints, and pivots along the way where you trust your employees to challenge problems they see.

Reply on news.ycombinator.com