For software that the developer can update instantly (an OS update doesn't count), then yes, this is a great methodology to live by. Hardware is a completely different beast, and costs significantly more for the purchaser and should be tested to extreme levels before launching.

I've yet to be won over to the fast-iteration model of software (or product) development, mostly because I think that presenting an unfinished, or unpolished, product to a customer is usually a bad idea. Even if you get it right later, the customer is still going to be left with a poor first impression.

Apple, despite their faults, is a great example of this: the majority of their products are carefully polished and finished, with a lot of attention to detail.

Obviously a company doesn't want to sit on a new product for too long, trying to perfect it before releasing it, and obviously a company should continue to improve its products and services continuously, preferably at a nice, steady rate. But, I'm steadfastly opposed to shipping unfinished products. I think it's bad advice every time I hear it or read it, and I think the negative parts of this review are a good example of why.

I know you mentioned fast-iteration, but you also mentioned MVP in your earlier comment, so I thought I refer to that.

When Apple first released iPhone, there wasn't an SDK publicly available. There wasn't copy and paste. There was also only EDGE/GPRS support, no multitasking (of any form except for a few built-in apps), no third party apps, no MMS, no SMS forwarding, no group SMS. It was only available in the US and only for AT&T subscribers. In many sense of the term, it is an MVP and it worked. It's just an MVP that was very polished.

As it rolled out releases, there were both enhancements and spots where they aren't as polished which was improved in a later release. Push Notifications in 3.0 + the coming Notifications center in 5.0 comes to mind.

So, they did an MVP with iPhone, initial features were minimum, but a selected subset of them are extremely polished. In fact if you look at many successful iPhone apps, this seems to be a very successful model.

Perhaps this approach only works on Apple's "target market". But I'd like to think this is an excellent approach when working with mass market consumers.

This link where Steve Jobs commented about Segway's marketing and launch is not totally relevant, but still interesting - http://hbswk.hbs.edu/archive/3533.html

That advice usually means that you're better off shipping 5 awesome features not 10 crappy ones.

"ship ship ship" is hard when it comes to hardware.

As for the software side of things, I'd say "QA", but I find the dev/release cycles at these major phone/tablet manufacturers to be unbelievably slow. As in, I really don't understand what they're doing a lot of the time. 5 volunteers working on CM can fix and implement features in the time it takes Motorola's team to do a `git merge` on Android and push it out to their phones (yes, even non-Blur phones).

I wonder if a lot of what we read about software development methodology is to blame for this? I would expect that individual and freelance developers, and developers at small companies, are more likely to practice "cowboy programming" -- use frameworks, glue them together, write code, handle (most) edge cases, exercise the most basic of best practices -- while larger companies, like Motorola, are more likely to practice something that a manager read about in a book or a consultant sold them on -- "waterfall development", "test-driven development", etc.

(Not that I have anything against those methods, but they would tend to slow down development in a corporate environment.)

I'm not sure it's so cut and dry. If you look at how CM releases are managed... they're very well done. Nightly build servers, good communication on their GitHub and Gerrit, very stable builds considering their nightly builds, all the dozens of phones exist as the larger CM project. I know you were speaking more generally, but I don't know that one or the other is always better, whether it's speed or style or development workflow.