Live data from Hacker News

Software philosophy: Release early, release often vs polished releases

blog.mugunthkumar.com

1–10 of 26 posts

Software philosophy: Release early, release often vs polished releases

#1
The world had cars, cameras and movies, much before Software. So, how and why did people got accustomed to this way of life, when it comes to Software? Will you accept if your new car, in its “version 1.0″ doesn’t speed up beyond 60? Will you accept if the car manufacturer promises a free “engine update” in the “near future”?

Software philosophy: Release early, release often vs polished releases
blog.mugunthkumar.com

Re: Software philosophy: Release early, release often vs polished releases

#4
I think release early, release often works well in some cases, especially for pre-release software. If you're working on the initial versions of something, that quick iterative process is key. Once you've released, however, you have an obligation to your users, so it becomes less of a valid mantra.

Re: Software philosophy: Release early, release often vs polished releases

#5
I expected this article to just recover some old material, but it actually raises some interesting points.

In particular, working on games, I believe (like with films), I don't think "release early, release often" is a good idea.

It might work with massive multiplayer games, where users tend to keep re-exploring the same content, but in general with games once someone has played a game once they don't tend to want to play it again.

I tried "release early, release often" with an iPhone game I wrote, and it was a mistake. The biggest problem is that users get angry if you take away, or significantly change, content from users. That's reasonable, but it means once you have added a level it is hard to take it away, even if you have a new, better level to replace it with.

Re: Software philosophy: Release early, release often vs polished releases

#6

I expected this article to just recover some old material, but it actually raises some interesting points. In particular, working on games, I believe (like with films), I don't think "release early, release often" is a good idea. It might work with massive multiplayer games, where users tend to keep re-exploring the same content, but in general with games once someone has played a game once they don't tend to want to…

> In particular, working on games, I believe (like with films), I don't think "release early, release often" is a good idea.

Although, as a counterpoint "release early, release often" works well for Minecraft.

Re: Software philosophy: Release early, release often vs polished releases

#7

In case, you can't access the article... http://webcache.googleusercontent.com/search?q=cache:http://...

Here's a better readable version of the cached article, thanks to Readability: http://www.readability.com/articles/o9rjarrr

Re: Software philosophy: Release early, release often vs polished releases

#8
Expectations from software are lower than other products like cars, televisions. A car breaking down in the middle of a drive to work is far more "severe" an incident than Internet Explorer hanging and crashing. Further, software engineering as a field is very very young, with a far lower barrier to entry, resulting in products and processes which are much less evolved and mature compared to other industries. I think these are important factors why software tends to have lower quality bars than cars or physical products.

Re: Software philosophy: Release early, release often vs polished releases

#9

I expected this article to just recover some old material, but it actually raises some interesting points. In particular, working on games, I believe (like with films), I don't think "release early, release often" is a good idea. It might work with massive multiplayer games, where users tend to keep re-exploring the same content, but in general with games once someone has played a game once they don't tend to want to…

Indeed. That's why 'small increments' are key there: as you say, don't significantly change content.

Blizzard have always followed this philosophy with their game balance changes: they make very small changes each patch. They are so careful that often, the effect they are trying to achieve won't be hit until after several patches. See, for example, druid effectiveness in Player-versus-Player: it's steadily, but very slowly, decreased since The Burning Crusade, as a result of druids being (perceived?) too good at surviving.

I mostly kept my Android game's existing content the same. The only changes I made were to slightly decrease difficulty each patch, as some areas were definitely too hard (the first boss could take up to 10 tries to kill, no matter what you did :).

One thing that users really love though is the release of a large chunk of content in one patch - e.g. a brand new area to explore. I don't think this translates well to websites or webapps - no matter how much of a killer 'feature', users can be very cynical or underwhelmed.

Finally, in enterprise software development, you need to be very careful with rapid release cycles as corporations are very dependent on the stability of your product, even if it's internal.

Horses for courses. The bottom line is to use the best strategy for the job.

Post reply on HN