Right. The perpetual beta.

Thanks for the update!

I guess I took your last bullet points incorrectly, then. I thought you were trying to point out that a development and deployment process such as IMVU’s couldn’t produce acceptable quality. If you’re not saying that, then I misunderstood.

What I am interested in, however, is the discussion that "Continuous Deployment" (small changes made frequently) to a live web application doesn't (or can't) yield desirable results.

What, specifically, did you read here that points to that conclusion?

In terms of the overall customer experience, I sense a difference between IMVU and, say, Flickr.

—Michael B.

What I am interested in, however, is the discussion that "Continuous Deployment" (small changes made frequently) to a live web application doesn't (or can't) yield desirable results. Given that every organization is different with respect to the tools and culture that surrounds their development process, and given that web applications are quite different from more traditional ("shrink-wrap"), continuous deployment isn't going to work for all forms of software development.

But for some, it does indeed work very well, and there's nothing magic about it. It was very much one of the reasons why Flickr was able to make incremental changes while at the same time scaling our infrastructure and maintaining high levels of availability and performance. Our developers and operations teams quite frankly can't imagine working any other way, and if at any point our availability or feature-shipping schedules were at odds with the rate of change we were introducing to production, our deploying multiple times a day would have slowed. It didn't, and I would attribute our success to both the tools we used and the culture we grew.

What I am saying is that when you focus your attention on something that customers don't value too much (like, say, deploying every half hour, assuming a 24-hour day; or deploying every 10 minutes, assuming an eight-hour day), you may reduce your perspective and vigilance on things that they may value more. There may be indirect value in being able to deploy very rapidly, but that begs questions on the quality of what you're deploying.

http://www.imvu.com/catalog/modules.php?op=modload&name=phpbb2&file=viewforum.php&f=6

Someone named Kara sent a comment recently in which she delivered quite a diatribe—strong enough that I wasn't inclined to publish it. However, she did provide a couple of links that were interesting.

http://www.trustlink.org/BusinessProfile.aspx?ID=206049811
http://www.rateitall.com/i-913414-imvu.aspx

—Michael B.

What I am saying is that when you focus your attention on something that customers don't value too much (like, say, deploying every half hour, assuming a 24-hour day; or deploying every 10 minutes, assuming an eight-hour day), you may reduce your perspective and vigilance on things that they may value more. There may be indirect value in being able to deploy very rapidly, but that begs questions on the quality of what you're deploying.

http://www.imvu.com/catalog/modules.php?op=modload&name=phpbb2&file=viewforum.php&f=6

Someone named Kara sent a comment recently in which she delivered quite a diatribe—strong enough that I wasn't inclined to publish it. However, she did provide a couple of links that were interesting.

http://www.trustlink.org/BusinessProfile.aspx?ID=206049811
http://www.rateitall.com/i-913414-imvu.aspx

—Michael B.

You could be absolutely right; it could be that the racket of having two audio tracks playing death metal at the same time is exactly what they intended, and that all you have to do is turn it down. And it could be that the 500 some-odd pages of forum complaints (noted in subsequent blog posts to this one) are insignificant—even the ones that refer to accounts being hacked and credits being lost. However, the general lack of care for detail suggests a strong possibility of more serious problems, evidence of which we did find later. Suggests, but doesn't confirm, so you might like to have a look at those subsequent posts and see what you think.

—Michael B. (brave enough to sign)

So essentially these arent "bugs", they are "nice-to-have-fixed". A "bug" would be something like not being able to talk to someone or chat repeating lines of input or something like that.

If the only bugs you have are for features which are "not crucial to hte product" then I say release!!

I think having to fix all these so called "bugs" borders on perfectionism.