Release early, release often is a philosophy where you release the product as soon as possible and rapidly iterate it to perfection by listening to your customers. A polished release, on the other hand is where your product, in its initial version is solid, lacks obvious bugs and has just enough features to satisfy a majority of your consumers. Most software companies adopt either one of this and that choice is not superficial. In fact, it roots down to the heart of the company’s ideologies.
Before you launch your next big product, website, app, read this and decide which side you are on.

Philosophy followed by them

Release early, release often, has always been the mantra of Linux kernel, software from Microsoft and plenty other open source software. Microsoft (and Microsoft developers) followed this philosophy since its inception. 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. Despite that, a few years later, Microsoft was able to catch up with the competition by following the release early, release often philosophy. In 1995, the same race happened between Microsoft and Netscape with browsers. IE 1.0 was no where near Netscape, but a couple of years later, the fourth iteration of the browser, IE 4 nailed it.

In late 90s, when the web became popular, updating your software (web application) became even easier and web application developers, continued to follow the same mantra.

The workflow of a web developer used to be like this.

Make a shitty website
Improve your website
check your visitor count

Improve your website
check your visitor count

Once your reach a satisfactory level, mark your release as final (remove that beta/gamma tag).

Later in 2004, when Google introduced their Gmail, it was known for the perpetual beta in the logo.
Flickr moved from alpha to beta to gamma(!) in 2006!

Philosophy followed by Apple

Apple on the other hand polish their products to perfection. May be it’s their “Think different” culture or may be it’s the ingrained attitude of the late founder, Steve Jobs, to make “insanely great” products relegating profits or business strategies.

The first version of iOS (then called as iPhone OS), did not even have MMS, included in even the dumbest phones out there. Yet, every feature that was available, worked really really well. The first iPod, despite being available only for Mac users, was a runaway success.

Consumer mindset outside of Software

Let’s for a moment think outside of Software. Let’s take movies for example. 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”.
The movies were great right from the first release and the producers and directors never “planned” to make their movie incrementally better. Of course there were sequels, but they were not “bug fixes” or incremental updates to the original movie. The same holds good for physical commodities like cars or cameras. Remember, 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”?

The reason was partly because, at least in the past, software was considered “Magical”. The first spreadsheet program (Lotus 1-2-3) can “sort” the marks of student in ascending order and made the process of calculating the rank among students in a class, super easy, fast and reliable. What usually took days, was accomplished within seconds using Software. Other commodities did not provide this level of satisfaction.

When something performs well on one area, human beings tend to be lenient in evaluating its performance else where. That “something” can be anything. A beautiful blonde girl who is “not so smart” or a restaurant that serves tasty food, but looks shoddy (or the other way round). This is precisely what happened to user’s perception of Software decades ago and unfortunately, has been continuing till now. A software that does one thing (sorting in this case) properly, but crashes often was still acceptable.

How Apple changed your consumers

Apple, on the other hand, tend to think differently. They never use the “beta” tag. (And when they do, it is still better than the competition). Look at the iterative changes that happens to any of their product. It, mostly remains same. The first iPod, still looks closely similar to the latest generation iPod classic and the first iPhone looks closely similar to the latest iPhone, the iPhone 4S and Mac OS X 10.0, looks closely similar to Mac OS X Lion. Leave software, even the light bulb invented by Edison a century ago, looks very similar in shape and size compared to the tungsten filament light bulb today. Contrarily, compare that to the control panel on Windows 95 to Windows 7 and the upcoming Windows 8 beta. It’s clear that, Microsoft didn’t nail it and they still haven’t nailed it.

With iPod, iPhone, iPad and several other products, Apple has proved that, Software can be done right, right from the initial version and has re-wired users’ brain to expect quality products even when it is Software. This can be seen on the ratings of same apps from the same companies on Apple App Store and Android Market Place. Ratings on Market Place is usually higher than on App Store even if the Android version is buggier. Apple users expect quality. They don’t tolerate sh*t.

These two philosophical differences might have stemmed from the thought process of Steve Jobs and Bill Gates who shaped the early software industry. Steve was a perfectionist. Anything less than the ultimate is a shitty product. Bill on the other hand was different. He was more focussed on the monetary aspects of things (that doesn’t automatically mean it’s bad) at the expense of quality.

What should you do?

The release early, release often mantra has created a notion that Software is unreliable and often buggy. Since most software are like that, consumers, more than not, aren’t willing to pay for Software just as easy as they would for anything else. When we learn this, we complain that, their attitude is wrong. We even go as far as comparing the cost of a Starbucks coffee to an app and say people don’t pay for software that costs a fraction of the price of a coffee. It’s not that people don’t want to pay. It’s more like, people are not interested in paying for something that they are afraid, might not work as advertised. To consumers, buying a software is more like taking a risk than buying a coffee. With Windows, the risk was viruses. With online, cloud only, web applications, it was privacy. With App Store, Apple has shown them, what trustworthy computing is mitigating a huge risk considerably. With App Store, the risk a customer takes is paying for a software that doesn’t work as advertised (or doesn’t meet the quality expectations).

While Apple was not doing well in late 90s, the industry thrived well on release early, release often mantra. It often worked since, funding the software product was easy when it was iteratively developed. But, it’s 2011 now. If you are making a iOS app, remember that your target audience are iPhone/iPad users. They don’t tolerate sh*t. The App Store is filled with high quality apps and if your app doesn’t meet that quality expectations, don’t expect a run away success. Make a polished product from day 1. If you are running low on budget/funding, don’t write software in the first place. If you were a movie producer, you can’t make a movie with half the money, release it and build upon that. Neither movies, nor cars or any other commodities are made like that. Don’t make a 0.8b release and expect users to tolerate it. Don’t promise *big* features on upcoming release. Some companies that I admire are Tapbots, Panic Software (they make the awesome FTP client, Transmit), AgileBits (the guys behind 1password). All of their products are “insanely great” right from day 1. Just because, something can be changed easily, doesn’t mean you should be changed frequently (iterated) even after release. Movies too had iterations, and cars had prototypes, but they existed only within the studio or the factory and never made it to the customers. You and me, the common man, doesn’t even know of their existence. Why can’t we build software like that? Why should you ship a product that’s not complete?

Let’s kill the notion that software can be made great only by rapid iteration. Make your next product an example of that.


Follow me on Twitter

  • Duane Johnson

    This is a thought-provoking article. I appreciate that you took the time to write these thoughts down so that others (like myself) can weigh both sides. One weakness present in your “pro-polished” argument is the time value of money. Different consumer categories are willing to exchange polish for now-ness.

    While a business always wishes for a “polished” product, its leaders (one consumer category) have to make time-critical decisions in the context of a competitive landscape. In such an environment, “shitty but doing something useful” is better than “nothing at all”. So while I agree that Apple-like consumers (another consumer category) want a polished product, in my view they don’t compare “apples to apples” with business consumers who need a product NOW that will give them an edge over another business.

  • Anonymous

    Release often, release early doesn’t mean you release buggy software. Linux was and is rather solid and stable. It just didn’t have all the features from the start. 
    You should never release buggy software, but for me release early is great attitude in many situations.

    • shayneo

      Yep. I remember when Linux came out. I was using a 286 and studying unix, and as a result the only option was Minix, which was released as a finished product. But Minix was buggy as hell, and since it was aimed at OS students, we where told “Fix it”. So I wrote my own driver for my incompatible WANG (yes, once upon a time thre was a computer brand called WANG, it amused me no end) hard drive controller, by following Andrew Tanenbaums book. But Linux more or less basically worked, and because Linux accepted patches and Minix didn’t , if a driver didnt exist, some guy (say… like me) who had learned from Minix could write them, and throw it into the mix. Unfortunately for me though, Linux was only for 386 or higher due to the lack of protected memory on a 286 (later down the track backports came about). Linux was release early release often and worked great, as long as you where a UNIX geek. But believe me, when OS/X came out, I think my jaw dropped so fast it cracked the tiles. But lets be honest here, OS X 10.0 was so buggy it was almost unuseable.

  • There aren’t many people with what it takes to make insanely great products because they need their customers to help them progressively define what it is. Release early and often and then improve is the next best strategy when there’s no good taste in the company. Imagine this in culinary field where chefs would serve food that were just edible at first.

  • Release often and early is also usually accompanied by copy shamelessly, also core philosophies of M$ and Google.

  • Quick releases means also that you can learn from your client, see what he needs, what he actually uses from what you’ve created, testing your assumptions. Selling buggy software is by no means a decent thing to do, but selling software with less features and building them through iterations seems quite logical.

    • Slast

      too bad my contradictory reply was not added to comments at is was debunking article authors thoughts so obviously yet constructively and all comments are filltered by moderators

      • Anonymous

        I read your comment and I thought it was published. I don’t moderate comments. Disqus puts comments that has links on waiting list.

    • Stevo8800 .

      Less features and buggy are 2 different words with 2 different meanings.