Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software philosophy: Release early, release often vs polished releases

blog.mugunthkumar.com

Post reply on HN
Print view View original

11–20 of 26 posts

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

#11

Post by mynegation »

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.

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

#12

Post by flyosity »

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.

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

#13

Post by alpswd »

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.

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

#14

Post by DanielRibeiro »

pyrhho wrote: post #6
CJefferson wrote: post #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…

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

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.

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

#15

Post by davesims »

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://www.amazon.com/Lean-Software-Development-Agile-Toolki...

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

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

#16

Post by revorad »

davesims wrote: post #15

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 y…

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

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

#17

Post by davesims »

revorad wrote: post #16
davesims wrote: post #15

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 y…

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

Offhand I can think of a few: ThoughtWorks uses it on most of their projects afaik. Github I believe does as well. They published an interesting blog on their deployment process a couple of months ago.

http://scottchacon.com/2011/08/31/github-flow.html

Where I work at LivingSocial the web application is deployed daily, sometimes dozens of times a day. I've recently taken over the Android project's infrastructure and we're in the process of implementing Continuous Delivery for that app as well.

David Anderson gives examples of implementing it at both Microsoft and Corbis, Bill Gates' other software company.

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

#18

Post by nicpottier »

revorad wrote: post #16
davesims wrote: post #15

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 y…

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

GitHub seems to fit that bill quite nicely.

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

#19

Post by wr1472 »

davesims wrote: post #15

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 y…

I thought the continuous delivery book was written by Jez Humble and David Farley. Fowler provides a foreword for it http://www.amazon.com/gp/product/0321601912?tag=contindelive.... Other than that I totally agree with you comments - Lean Continuous and Agile are not orthogonal to Quality.

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

#20

Post by Spearchucker »

davesims wrote: post #15

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 y…

Some good points, but (there's always a "but" :-) as with most of these, let's call them modern processes (maybe not even that modern if you consider what the likes of Peter DeGrace were saying back in 1990), continuous delivery forces an engineering paradigm onto the (often unwilling) user.

What does the constant barrage of (for example) iTunes or Flash updates do to the user's perception of quality?

What is the impact of the Chrome release cycle on a corporate environment that needs to test each revision on a model office, in case there's an impact on one business-critical application or other?

Post reply on HN