One of my favorite essays is The Rise of Worse is Better by Richard Gabriel, which describes the distinction between what he calls the “MIT approach” and the “New Jersey approach” with respect to software development. In short, the MIT approach is about solving a problem correctly and completely from the start. That is, every possible use case and functionality is carefully designed up front and the result is a beautiful, complete piece of software. The New Jersey approach, which Gabriel describes the philosophy behind UNIX and C, is to build systems iteratively, perhaps at the expense of building the perfect solution.
With most complex systems, the first 90% is much easier than the last 10%, and the New Jersey approach is to get that first 90% out to market as fast as possible, assess its success, and solve the last 10% in smaller increments. Gabriel argues that releasing something worse and allowing the community/market to respond as you improve it is better than waiting to release until you have the final, perfect solution.
Most startupy-type folks will tell you that the New Jersey approach is obviously better. Release quickly and keep pumping out features, pay attention to actionable metrics, and move fast and break things.
In contrast, Apple seems to be following the MIT approach. Their philosophy towards releasing products has been to release a brilliant, perfect new innovation every year or so to great fanfare. The iPod, the iPhone, the iPad, etc are all revolutionary devices that haven’t really been fundamentally changed since their initial release. Apple does it right the first time around.
The release policies of Apple’s App Store reflects the company’s school of thought towards product development. It takes days/weeks/months to get the app approved by Apple, and subsequent iterations require the same rigorous review. Since there’s a huge cost to release, app developers are careful to ensure that each version is as perfect as it can be. Steve Jobs was a brilliant visionary in the world of personal computing, but not everyone is. Chen says it best when he describes that the App Store’s release process “lets people indulge in a little fantasy that they too are Steve Jobs, and once they launch a polished product after months of work, they’ll be a huge success, too.”
The Google Play Store, on the other hand, is a wild west of Android apps. There’s not a review process. Anyone can release anything as many times as they want. Between Play Store propagation and user update cycles, it takes half a day or so to get a new version out to the masses, but comparatively, this is much, much faster than updating your app in the App Store. Given the quick turnaround time, app developers don’t have to be afraid to try a new feature, even if it’s not quite right yet. They can ship incremental versions frequently based on observed usage to steer their product in the right direction as fast as they’re able.
Distributing apps through the Play Store allows a team to take the New Jersey approach and find product/market fit as soon as possible. There are other factors to consider when deciding which mobile platform to use first (ease of development, target user base, etc), but I hope that Apple sees the App Store’s model of infrequent, monolithic releases as a competitive disadvantage and finds some way to tighten the app development iteration cycle.