Yahoo Live's Scaling Problems Prove: Release Early and Often - Just Don't Screw Up

Tech Crunch chomped down on some initial scaling problems with Yahoo's new live video streaming service Yahoo Live. After a bit of chewing on Yahoo's old bones, TC spat out: If Yahoo cant scale something like this (no matter how much they claim it’s an experiment, it’s still a live service), it shows how far the once brightest star of the online world has fallen.

This kind of thinking kills innovation. When there's no room for a few hiccups or a little failure you have to cover your ass so completely nothing new will ever see the light of day.

I thought we were supposed to be agile. We are supposed to release early and often. Not every 'i' has to be dotted and not every last router has to be installed before we take the first step of a grand new journey.

Get it out there. Let users help you make it better. Listen to customers, make changes, push the new code out, listen some more, and fix problems as they come up. Following this process we'll make something the customer wants and needs without a year spent in a dark room with a cabal of experts trying to perfectly predict an unknowable future. Isn't this what we are supposed to do?

Then give people some space to work things out before you declare their world ended and that they are an embarrassment to their kind.

Comments

[William Pietri]

As an agile coach, I both agree and disagree.

On the one hand, yes, TechCrunch should be a little kinder. To be fair to them, they often do ignore success failures at smaller companies. But you're right that beating on new things too much saps courage.

On the other hand, there are ways to handle this issue. For example, they could have started out launching it in-house. The could have done a limited beta. Or they could have built things to fail gracefully under load.

A lot of agile proponents are also big on testing, and I have to wonder if they did that here. Did they just get way more users than they imagined? In that case, I'd call that a product management failure, one Yahoo should have enough experience to avoid. If it instead just fell over, I'd be feeling kinda queasy were I on that team.

For me, the bottom line is that you only get one first impression with a user. Like any precious resource, it pays to manage that carefully. I'm an adamant proponent of "release early, release often", but I think you can achieve agility without getting a lot of egg on your face like Yahoo did here.

[Larry Ludwig]

Wasn't it also TC that was also pumping how great Media Temple's Grid service was so great and scalable?

http://www.techcrunch.com/2006/10/17/media-temple-crushes-shared-hosting/

Media Temple has had many issues (just read the comments on this blog alone).

So for them to pump one company (who they host with), while putting down another makes you wonder how unbiased they are..

IMHO it's important to understand that issues will occur (even for a non "beta/experimental" version) and how quickly they are dealt with, than being perfect. Believe me Yahoo knows how to scale their apps.

[Todd Hoff]

> bottom line is that you only get one first impression with a user.

Doesn't that imply not releasing early because it's unlikely you'll have a product worthy of another look? Abandonment rates are high. Most people who try something don't stay with it anyway, so that initial flow of users isn't as a key as building something of long standing value. And don't forget Yahoo has a rather unique ability to cross promote between properties so their ability to build traffic over time is strong.

> Or they could have built things to fail gracefully under load.

It seemed pretty graceful. They said their service could handle more people. What might have been a better approach?

> Yahoo should have enough experience to avoid.

Imagine how the meetings might of went. Here's our cool new service and here's our initial build out requirements to handle 200 million potential users. It will cost a zillion dollars and take a few years to build out, but we'll be able to handle Yahoo scale. Hold on their bucko. How much money will this service make? We don't have that much data center space to allocate for an unproven product. We'll have to take away resources from revenue producing properties and that's not really a good thing right now. So why don't you start smaller. See if the service will become popular. And then we'll see about more resources later. OK, that seems reasonable. Let's do that.

> but I think you can achieve agility without getting a lot of egg on your face like Yahoo did here.

It's really a catch-22. You are still blamed for every failure that could have been solved with a little more time and resources but you are specifically told you have neither. Maybe a limited invitation only beta would have been a better throttling mechanism, it's just that the reaction seems so far out whack compared to what's in play here and the attitude is dangerously punitive.

[Alex Barrera]

The point that TC wants to rise, and I'm not sure I agree with them, is that being Yahoo such a big company they shouldn't act as a start-up. It's just as if Microsoft throws a new OS (Vista :P) with many beta (or even alpha) parts and tells people to test it (they actually do that also). Guess what? People get pissed because supposedly MS is a corporation big enough to have beta testers of their own. I think TC is trying to tell the same story about Yahoo which, it's a fair enough critic.

Another story is if you warn people about your app being in alpha, moving it to something similar to google labs, etc. Then you can't really say anything as you've been warned that the application might crash under load and people will understand it. Yahoo, afaik, did neither, and so people get pissed when they test a service that isn't from an under founded start-up or a beta product.

Is it nice to kick Yahoo around about it publicly? Don't think so, but well, its TC, and they sell that :)