Twitter bashing has become a bit of a past-time for some people. I don’t think that the criticism leveled at Twitter is fair or accurate. It is generally based on a misunderstanding of the technical problems they are facing. In the case of TechCrunch, it’s a desire to drive traffic to the TechCrunch website by fabricating conflict and making personal attacks.
Twitter has had a hard time scaling. This is obvious to anyone that uses the service, and is readily admitted by the people behind Twitter. The present problems have brought out all of the Armchair Architects, and I’ve seen a lot of commentary stating “I don’t understand why this is so hard, all you need to do is [insert gross over-simplification of the problem here]”. It’s very easy to apply some 20/20 hindsight to this problem, but another thing entirely to be in the trenches day after day working to keep Twitter up and running while trying to make large-scale changes to fix the underlying problems.
Here’s the thing. Twitter was started as a side-project inside Odeo. It was developed in Ruby on Rails, the same tool that they had used successfully to build Odeo. While this choice is a major discussion point for their critics, it seems to me to have been a very reasonable decision. Ruby on Rails was what they were familiar with, and at first glance seems to be a good fit. I suspect most people would have made the same decision, given the same situation. The bottom line: They made the best decision they could, based on what they knew at the time. Keep in mind that nobody even knew whether Twitter would gain any traction – certainly none of them could have anticipated the warm reception it has been given.
Obviously their existing architecture isn’t working. The fine folks at Twitter have figured this out, and they are busy rebuilding the system to handle the current load and scale accordingly. This isn’t an overnight fix – it will take time to rebuild Twitter with all-new innards. Let’s be patient. Frankly, the internet needs to take a collective chill pill on this topic.
If you’re not following me on Twitter, you can remedy that here.
I’ve had my own list of complaints, and have been pondering my own complaint post, but not because I think scaling should be simple. I haven’t seen them list what their problems are and what they are facing. They just say, our server died, we are working on it. Thanks, but I want to know more. Why did the server die? Have they considered using any of the services from Amazon to get them from here to there? Are they currently just trying to restore a server or are they working on full framework changes with twitter’s underlying code structure?
I love twitter, but now that I’ve gotten used to using it, I am upset when it’s down, I look forward to the information that I get with it. Having it down is frustrating, and that’s probably the same sentiment from everyone else out there complaining about it being down. Sure their blogs are about the architecture, but they are really just saying, I rely on this service and I hate when it’s down.
I just ran across another service pownce.com that looks like it is a twitter clone of sorts. If they can prevent the same scaling problem, it’s possible that they will end up gaining some of the users from twitter. An unhappy customer will go where something equal is being offered, if it’s just a little better, in this case reliability could be enough to win.
Well to be fair, Odeo had serious performance problems of its own, even at a fairly young age.
Twitter began as a research and development project inside San Francisco start-up company Obvious, LLC in March 2006. It was initially used internally by the company, and officially launched in October 2006.