Release early/release often for commercial software?

Question

Are there anyone with experiences/examples on releasing early/releasing often for commercial software? Does it work?

I was thinking of VMware where they have a lot of revisions release between each major version. And the installation experience was awful, sometimes they would break the existing VMs and other times the VMware Tools inside guest OSes would malfunction/not install. It's just horrible.

And I was thinking of ClickOnce deployments as well, since with ClickOnce when you update your software, all clients automatically gets notified of the release, and with one-click they're updated to the new version. If your software has bugs, then they'll automatically "upgraded" to get those bugs as well.

Do you have experience\example\suggestion to applying the release early/release often principle to commercial software?

I'm looking to apply it to one.

Answer 1

I think it always will depend on your market or customer base. Changing/upgrading software is always painful and even more painful in some environments and companies. Fast release cycles can be disruptive. These disruptions often extend to your internal operations too, depending on how well feature creep is managed by marketing/management.

So, the classic ever true 'it depends' answer rings again.

If you are really adding value to the product, then customers especially new ones will want it. The best case, is to remove the upgrade change pain, as in, it works the same, but better in obvious ways. Great.

Answer 2

It depends on your resources. If you're MicroSoft, you can early-release a bug-ridden POS that rhymes with Sista, and rely on your marketing power to make people forget their early experiences with the product.

If you're hoping for good word-of-mouth, releasing an early version is not a good idea (unless you're planning to change the name or something before the final release).

Answer 3

If you're going to do this, ensure that when people buy your product that they will get free upgrades to new versions for a year, or some other period of time so that they don't feel like they got ripped off when a new version comes out 2 months after they bought a copy. Also, ensure that you support old versions so that those who don't want to upgrade, just want bug fixes can do so without risking breaking their current installations with new versions of the software. I personally think it will be more work, but you will end up with a better product, and you will allow people using your software to take more advantage of newer features faster if they choose to.

Answer 4

Kenny is right: it depends.

We work on Enterprise software, where a customer may run an internal 3+ month project to upgrade to a new release. In that environment frequent releases do not work. Customers will stay on an old release for years and we have to keep supporting them, so the more releases that are active the more support work.

At the other extreme I was running Google Chrome and read about a beta refresh. I went to see how to get it and discovered that Chrome had already updated itself. If there was any notification I missed it, and that is fine with me.

The main question is how disruptive a new release is. For example, if MS released new versions of Visual Studio every 3 months with a new .NET version, C runtime, etc then we would spend a good portion of our time just dealing with the upgrade, which would not be good. But if they want to release new versions of Windows media player with some new widget that is fine with me -- just make the download/install process as seamless as possible.

Answer 5

Pay attention to the man behind the curtain.:
The thing that Release Early - Release Often practice wants you to do is to have fail early and fast instead of at the end of the project, when its too late. It gives you more opportunities to show what you are building to the end customer, get valuable feedback and adapt at a lower cost. The person in the 'customer' role must be able to easily obtain the latest release; play with it and respond with constructive feedback as regularly as possible.

In case you're building something critical e.g. something that monitors or controls a power plant, you'd probably want to be careful with this practice. You don't want people out with torches as feedback for your new release. In such cases, it makes sense to deploy regularly to a test bed, watch it for X days (as per your confidence level) and then go LIVE! You can give your customer access to this test bed to play and build up his confidence meter.
If its a non-critical application and you've had a good historic record of good releases, do something like ClickOnce.. but also make sure its equally easy to rollback for the customer.

Answer 6

We run a SaaS application, so in principle it can be updated as often as we like.

On the other hand, in practice, it gets only a few major releases per year (smaller patch releases are put out every few weeks typically).

The reason for this is that releases create disruption for operations staff; sometimes part of the application needs to be taken down. Every for non customer-facing changes, there is a lot of work that goes into actually doing the release as opposed to doing the engineering.

So while StackOverflow seems to get updated every few days, we don't do anything like that. Several bugs may be fixed in a day, but they are fixed in a subsequent release which goes out as a "big bang". Or something.