I read a posting in the Agile Usability Discussion Group regarding Netflix and a fast iteration development cycle. There was a link to an article on uie.com regarding the subject. If you’ve never seen the Netflix website (or used Netflix, for that matter) — first, shame on you. You should use Netflix because it is fantastic and it will help my stock holdings. 
The Netflix website is consistently voted as the best website available, and I agree. The article details how their development team uses fast iterations to get things done — did you know that they release production software every two weeks?
“We make a lot of this stuff up as we go along, I’m serious. We don’t assume anything works and we don’t like to make predictions without real-world tests. Predictions color our thinking. So, we continually make this up as we go along, keeping what works and throwing away what doesn’t. We’ve found that about 90% of it doesn’t work.” — Netflix Lead Designer
I love this philosophy. I’ve always been a fan of quick iterations, with releaseable software as a result of each iteration. That’s the key. But I have to admit, it’s a lot easier said than done.
Fast iterations can be used with web development fairly easily. In fact, with anything where there is “one” customer, it can work — a public website is exactly that.
But we have constant problems trying to get it to work with software that is bundled and distributed to customers. It is more difficult, but certainly not impossible. In those cases, its important to have a fake customer. Iterations should still occur quickly, and software should be in a releaseable state at the end of an iteration. It isn’t necessarily released to your customer, but instead QA people can be the customer.
It’s not as good as Netflix’s iterations, but it is certainly better than nothing. Software design is always a fluid process. As long as you can get some kind of feedback quickly, and then adapt accordingly, you are much better off.
Don't Mess With Doctor Dream
