Five Things Twitter Shouldn’t Be Doing
Twitter is at an awkward point in their lifetime. It’s their age of prepubescence. The time in every young tech companies life when it’s time to face some of the issues that will thrust them into their teenage and adult lives. And just like any pre-teen, they are bound to make some pretty stupid decisions, while going through some awkward changes, physically and mentally.
Here are five things I think Twitter shouldn’t be doing at this confusing point in their life.
1. Breaking their service, in order to fix their service: With the problems Twitter has been having recently due to cache issues, their servers had pretty much come to a standstill while their cache service underwent an “unscheduled” restart (according to the official Twitter blog) two nights in a row. Twitter is a service which is in dire need of a black box server. A place set aside for a scaled replica of the Twitter service, where these “fixes” can be tested before implementation. Twitter has admitted that these cache errors are due to mistakes they had made. In other words, it was preventable.
2. Keeping the community in the dark: When Twitter goes down, it goes down hard! The community is made of such a high percentage of power users (24% are power users I believe, don’t remember where that stat is from) that the service being down causes panic among other social communities. The thing that really gets my goat about these outages isn’t so much that Twitter is down, but the fact that it is actually DOWN. No warning of respect shown to the community at all. No LOLCat maintenance image. All we get is a dead server. And it’s pretty damn shitty and disrespectful to the Twitter community.
3. Sticking with their Ruby on Rails architecture: The second that the peeps over at Twitter noticed a spike on the new users chart, that should have been their cue for ditching Ruby On Rails As far back as March 2007, Twitter developer Alex Payne has acknowledged the fact that Rails just doesn’t hold up as far as scaling is concerned. In an interview Alex Payne said this:
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both
So if Twitter has known about these issues for more than a year, why hasn’t there been some sort of plan of action for when Ruby must go. A lot of the problems we’re seeing now might be due to the fact that Twitter has turned a blind eye to scaling up until now.
4. Banning pseudo-”spammers”: When the Twitter community called for a solution to the spam problem which has been plopping itself on the service the last few months, the answer seemed to be the Twitter Blacklist. Based on a system called the “Follow factor” (how many the users follows divided by how many follow them), the Blacklist figures they can determine who’s on Twitter with questionable motives in mind. Twitter is even working with the Blacklist founders to block these spammers. There was a point where I was following nearly three times as many people as were following me. And I certainly wasn’t a spammer.
I was just having fun reading what these people were saying. I found myself scared into deleting a portion of the people I followed, out of fear of being scoped out by the Blacklist police. There are more effective ways for dealing with spammers, whether it be a CAPTCHA system for tweets in fast succession or even a CAPTHCA system for adding followers.
5. Jumping the shark: If you were using Twitter a few weeks back, at the time when Twitter first added their mouse-over shading effect for tweets on the timeline, you might remember that this added feature caused havoc on the timeline interface. You’d click on the reply arrow, and you’d be teleported to the users page. The same thing happened when you clicked on ANY aspect of the tweet.
This, my friends, is an example of Twitter jumping the shark with new feature implementation. This fifth and final “shouldn’t” can be cycled back to the first one. Some of these features are simply cosmetic, but cause disastrous after effects for the community. Twitter shouldn’t be making these features live without fully testing their consequences.
—–
Now do I hold these issues against Twitter? Of course not. Getting everything perfect with a service such as Twitter is about as possible as repairing the engine of a race car as it travels around the track at nearly 200 mph. Though I think these facts are a nice starting point for some problems which I see as being preventable.
Filed under social |17 Responses to “Five Things Twitter Shouldn’t Be Doing”
Leave a Reply
Great post. Especially the point about not keeping users in the dark. I find that particularly frustrating in this day and age.
They should just exploit the traffic for ads so they can get better servers. That is the plan right?
CAPTCHA? LOL
I have to disagree with you on some of these points, I’m afraid. (And why make this a negative post? All the comments I’ve seen from you recently about Twitter have been “they shouldn’t be X”! Why not make the focus the thing that they should be doing?)
1) I think you’re conflating two issues here: upgrading without testing, and making the service inaccessible in order to fix it. The first is flatly unverified - as nice as a test server is in theory, the necessary minute differences between the test and the live can spell disaster regardless of how thoroughly you test. (You actually tacitly make this point, although it’s not immediately obvious: you mention that they need a scaled-down version of Twitter to test on, and go on to talk about how RoR doesn’t scale up well. The implication is that things that work on the scaled-down test server will blow up on the scaled-up live server.) I’ll grant, though, that this kind of error probably would have been caught in testing. The second is sometimes necessary; in order to upgrade services, you sometimes have to take them down, even if only briefly.
This isn’t to say that I don’t think upgrades should be tested; that couldn’t be farther from the truth. But live servers are wild and woolly beasts, and even testing sometimes isn’t enough to shear off any problems.
2) This one I’ll agree with. Although to be honest, the Twitter blog does constitute informing the users. Still, they could do better.
3) As I understand the situation, this is part of why the lead architect left Twitter last month. Now that he’s moved on, they can get on with migrating.
4) I don’t know anything about Twitter cooperating with TwitterBlacklist, and I’ll be disappointed if that turns out to be the case. TwitterBlacklist is an ill-conceived, mean-spirited blight on the Twitter community, and the sooner it goes away the better off we’ll be.
5) I’m not sure what you mean by “jumping the shark” here - it doesn’t seem to be what jumptheshark.com means by it - but really, this doesn’t just cycle back to the first issue, it’s the same issue in disguise. Testing an upgrade to the back-end and testing an upgrade to the front-end are both just testing.
All of this said, I don’t think you’re wrong to be frustrated. But I do think you’re approaching it from the wrong angle. Does making a list like this really do anything but vent your frustration?
Great post, and awesome points… I think number 2. is the sticking point.
[…] Dobrow (@anjrued) has a new post up on five things Twitter shouldn’t be doing. Now, people who have known me for any length of time - hell, anyone who’s hit […]
Andrew, I’ve written up a counterpoint here: http://www.etherjammer.com/blog/?p=387 (”Five things Twitter should be doing”).
First thing Twitter Shouldn’t Be Doing: Be Unstable:)
The “follow factor” is no longer accurate at tracking spammers. I have started to notice that spammers are following people and then immediatly unfollow people to keep their “follow factor” low. Once someone accepts their follow, the bot will follow back again resulting in two follow emails.
[…] more than anything is for Twitter to realize that the technical problems may soon be dwarfed by the social problems. It’s in my own best interest that wherever I invest my conversation and build community […]
To me, the most important is number 2. I could live with the other problems if they would tell us things as they’re happening…not hours (or sometimes days) later.
Dude, you totally misrepresented Al3x’s quote. He -never- said “rails doesn’t scale,” he said that to use it in a high usage application you need to either get rid of the slow dev-friendly stuff that makes it easy to code small stuff with, OR keep the friendly stuff and port the slow parts of the app.
I think a great way that Twitter can alert users of upcoming outages is to send it out in the public timeline for all users to receive. If they can do it with ads in Japan, then they can leverage that to update the entire twittersphere.
I read this post and Chris’ post. Great points that I hope @ev et al. will read and consider.
Facebook went through this same period and I railed against them much in the same way. For some reason Web 2.0 companies don’t seem to follow standard, time-worn development processes. You don’t change things in the production environment: IT 101. I saw proof of this when the search bar bounced around the page one day on Twitter.
And I have to wonder why Twitter is even bothering with mouseover effects when they can’t keep the servers up.
But enough bashing. Facebook finally got it right and implemented a better production migration process. Twitter can too, but when?
I’d also argue that the Twitter service is pretty simple compared with Facebook or My Space. They’ve been experiencing problems for quite some time. If Rails is the issue, invest in rewriting some of the app. I’m a developer. I know how hard it can be to develop a scalable system, but I also know that being stubborn about bad choices doesn’t fix the problem.
Twitter is a great service and I’m tired of all the negativity, but the outages are frustrating. What can we do to help you, Twitter?
[…] has some major issues with customer satisfaction. Regular, unexpected outages are causing significant frustration for its users and many are wondering what can be done to escalate the […]
“So if Twitter has known about these issues for more than a year, why hasn’t there been some sort of plan of action for when Ruby must go. A lot of the problems we’re seeing now might be due to the fact that Twitter has turned a blind eye to scaling up until now.”
Ruby and Rails aren’t interchangeable terms - Ruby is the language, Rails is the framework. It’s Rails’ ORM - ActiveRecord- and the rest of its’ magic that’s now causing the bottlenecks - if we are to believe it’s truly Rails causing the problems.
Ruby is a programming language - and a wonderful one at that. Changing away from Ruby into another language won’t stop downtime or ‘fix’ their problems.
[…] ben alvast niet één van die voorstanders (zoals Scoble) om Twitter de rug toe te keren (vanwege de outages en beperkte communicatie) en enkel en alleen voor Friendfeed te kiezen of met Twit-Outs om aandacht vragen bij het Twitter […]