4 ms·

Software philosophy: Release early, release often vs polished releases

23 points by MugunthKumar 15y ago

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”?

suhastech 15y ago
In case, you can't access the article... http://webcache.googleusercontent.com/search?q=cache:http://blog.mugunthkumar.com/articles/software-philosophy-release-early-release-often-vs-polished-releases/&hl=en&client=safari&tbo=d&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
- marceldegraaf 15y ago
  Here's a better readable version of the cached article, thanks to Readability: http://www.readability.com/articles/o9rjarrr http://www.readability.com/articles/o9rjarrr
MugunthKumar 15y ago
Site ycombinatored. Please use Google cache.
rmccue 15y ago
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.
CJefferson 15y ago
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.
- pyrhho 15y ago
  > 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.
  - DanielRibeiro 15y ago
    It worked great for Minecraft: many ideas from the mod community were siphoned back into the main game. The iPhone does make this difficult, as a release usually takes one week to go through Apple's approval system. Therefore you can't make mistake today and fix it tomorrow. This is what the Android market is good for. However the stores are different, so lessons learned on the Market may not suit your iPhone audience.
- davedx 15y ago
  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.
adsahay 15y ago
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.
- igouy 15y ago
  "[O]ther products like cars, televisions" include embedded control software.
squish101 15y ago
Very interesting article. Well done sir!
mynegation 15y ago
Releasing well-polished version of products makes sense most of the time. With all due respect to movie directors, engineers, software developers and game designers you _mostly_ know how to do a movie, a car, an MP3 player, or yet another take on video editing program. Sometimes, however, things are so new that the only way to get to the good result fast (or, to get to the good result at all) you need to release early, release often. Lotus 1-2-3 was such a huge improvement over paper sheets and such a new idea that it totally warranted "release early, release often" mantra.
flyosity 15y ago
The software successes I see in the App Store take a two-pronged approach: launch with a polished 1.0, but then iterate quickly with similarly well-built .1s, .2s, etc. The upside of releasing multiple updates after a good 1.0 is out the door (on the App Store at least) is that your app shows up more frequently in the App Store Updates area so if people haven't used your app in awhile, they may be incensed to give it another try. A downside of releasing too often is that all the great reviews you got for the 1.0 will be gone once enough reviews for 1.1 are in. If all you did was drop a bugfix into 1.1, you may not receive as many glowing reviews and your overall app rating will drop. This really sucks, but it's a reality of the ecosystem.
alpswd 15y ago
The Release Early/Often example describes a situation of releasing a product that does not have all the features of its competitors: "The Windows Operating System, in the initial version (1.0) did not support overlapping windows which was a breakthrough feature on the then contemporary Macintosh." Identically, the Polished Release example also describes a situation of releasing a product that does not have all the features of its competitors: The first version of iOS "(then called as iPhone OS), did not even have MMS" Seems like the author didn't pick a great example to demonstrate a Polished Release.
- ranit8 15y ago
  His example outside of software[1] is not the best either. Movies do have "versions", they are called cuts; an example of multiple published cuts for a movie is Blade Runner. [1]> Every single release of a movie, whether it is The Jurassic Park and its sequels or The Matrix and its sequels or Steve Jobs’s own Toy Story and its sequels never had "versions".
davesims 15y ago
Another week, another false dichotomy article on HN. If there's an inverse correlation between the speed of deployment and the quality of your software, you're doing it wrong. The Continuous Delivery philosophy is borrowed from Lean Manufacturing, and a fundamental tenet of that movement is "Build Quality In." In fact Lean is nearly synonymous with TQM, or Total Quality Management. If you've separated the two, then you've missed the entire point. This tenet is carried over into the software world by Martin Fowler in his book Continuous Delivery, as well as all of the major advocates of lean software processes, for instance David Anderson and the Poppendiecks in their highly influential series of books on Lean Software. Essential to a successful continuous deployment process is unit testing, continuous integration and built-in testing processes all along the way to feature deployment. These should be focused on quality all along the way: that's the point of continuous deployment, to allow for focused feature development that is highly tested and can be released with higher confidence than the old method of multiple feature release, which are heavy, harder to test and have more integration concerns. The point of fast releases should never be to allow for "shitty software," but rather to deliver features that users can enjoy as soon as possible, create a process where deployments become highly automated, low-risk events, and gather feedback early and often on the experience of users with finished polished features so that effective product evaluation is happening constantly and the company can adapt quicker to new data and new trends. A quick perusal of even the first chapter of any of the major volumes on Continuous Delivery should clear this up: http://martinfowler.com/snips/201006021426.html http://martinfowler.com/snips/201006021426.html http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/ref=sr_1_1?ie=UTF8&qid=1322492548&sr=8-1 http://www.amazon.com/Lean-Software-Development-Agile-Toolki... http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381 http://www.amazon.com/Implementing-Lean-Software-Development... And there's a fantastic presentation by David Anderson on Kanban on InfoQ, which nicely illustrates why quality is one of the major reasons you should consider a rapid release process like Kanban: http://www.infoq.com/presentations/kanban-for-software http://www.infoq.com/presentations/kanban-for-software
- revorad 15y ago
  Can you point to any examples of high quality software products created using the methodologies you mention?

23 points by MugunthKumar 15y ago

suhastech 15y ago

In case, you can't access the article... http://webcache.googleusercontent.com/search?q=cache:http://blog.mugunthkumar.com/articles/software-philosophy-release-early-release-often-vs-polished-releases/&hl=en&client=safari&tbo=d&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...

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

MugunthKumar 15y ago

Site ycombinatored. Please use Google cache.

rmccue 15y ago

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.

CJefferson 15y ago

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.

pyrhho 15y ago
> 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.
- DanielRibeiro 15y ago
  It worked great for Minecraft: many ideas from the mod community were siphoned back into the main game. The iPhone does make this difficult, as a release usually takes one week to go through Apple's approval system. Therefore you can't make mistake today and fix it tomorrow. This is what the Android market is good for. However the stores are different, so lessons learned on the Market may not suit your iPhone audience.
davedx 15y ago
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.

adsahay 15y ago

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.

igouy 15y ago
"[O]ther products like cars, televisions" include embedded control software.

squish101 15y ago

Very interesting article. Well done sir!

mynegation 15y ago

Releasing well-polished version of products makes sense most of the time. With all due respect to movie directors, engineers, software developers and game designers you _mostly_ know how to do a movie, a car, an MP3 player, or yet another take on video editing program. Sometimes, however, things are so new that the only way to get to the good result fast (or, to get to the good result at all) you need to release early, release often. Lotus 1-2-3 was such a huge improvement over paper sheets and such a new idea that it totally warranted "release early, release often" mantra.

flyosity 15y ago

The software successes I see in the App Store take a two-pronged approach: launch with a polished 1.0, but then iterate quickly with similarly well-built .1s, .2s, etc. The upside of releasing multiple updates after a good 1.0 is out the door (on the App Store at least) is that your app shows up more frequently in the App Store Updates area so if people haven't used your app in awhile, they may be incensed to give it another try. A downside of releasing too often is that all the great reviews you got for the 1.0 will be gone once enough reviews for 1.1 are in. If all you did was drop a bugfix into 1.1, you may not receive as many glowing reviews and your overall app rating will drop. This really sucks, but it's a reality of the ecosystem.

alpswd 15y ago

The Release Early/Often example describes a situation of releasing a product that does not have all the features of its competitors: "The Windows Operating System, in the initial version (1.0) did not support overlapping windows which was a breakthrough feature on the then contemporary Macintosh." Identically, the Polished Release example also describes a situation of releasing a product that does not have all the features of its competitors: The first version of iOS "(then called as iPhone OS), did not even have MMS" Seems like the author didn't pick a great example to demonstrate a Polished Release.

ranit8 15y ago
His example outside of software[1] is not the best either. Movies do have "versions", they are called cuts; an example of multiple published cuts for a movie is Blade Runner. [1]> Every single release of a movie, whether it is The Jurassic Park and its sequels or The Matrix and its sequels or Steve Jobs’s own Toy Story and its sequels never had "versions".

davesims 15y ago

Another week, another false dichotomy article on HN. If there's an inverse correlation between the speed of deployment and the quality of your software, you're doing it wrong. The Continuous Delivery philosophy is borrowed from Lean Manufacturing, and a fundamental tenet of that movement is "Build Quality In." In fact Lean is nearly synonymous with TQM, or Total Quality Management. If you've separated the two, then you've missed the entire point. This tenet is carried over into the software world by Martin Fowler in his book Continuous Delivery, as well as all of the major advocates of lean software processes, for instance David Anderson and the Poppendiecks in their highly influential series of books on Lean Software. Essential to a successful continuous deployment process is unit testing, continuous integration and built-in testing processes all along the way to feature deployment. These should be focused on quality all along the way: that's the point of continuous deployment, to allow for focused feature development that is highly tested and can be released with higher confidence than the old method of multiple feature release, which are heavy, harder to test and have more integration concerns. The point of fast releases should never be to allow for "shitty software," but rather to deliver features that users can enjoy as soon as possible, create a process where deployments become highly automated, low-risk events, and gather feedback early and often on the experience of users with finished polished features so that effective product evaluation is happening constantly and the company can adapt quicker to new data and new trends. A quick perusal of even the first chapter of any of the major volumes on Continuous Delivery should clear this up: http://martinfowler.com/snips/201006021426.html http://martinfowler.com/snips/201006021426.html http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/ref=sr_1_1?ie=UTF8&qid=1322492548&sr=8-1 http://www.amazon.com/Lean-Software-Development-Agile-Toolki... http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381 http://www.amazon.com/Implementing-Lean-Software-Development... And there's a fantastic presentation by David Anderson on Kanban on InfoQ, which nicely illustrates why quality is one of the major reasons you should consider a rapid release process like Kanban: http://www.infoq.com/presentations/kanban-for-software http://www.infoq.com/presentations/kanban-for-software

revorad 15y ago
Can you point to any examples of high quality software products created using the methodologies you mention?