I saw some very concerning issues on the Twitter development list today, and my frustration has only been increased after reading some of the claims of Blaine Cooke today on TechCrunch. Yesterday, the one thing that seemed evident, and perhaps I’m wrong on this, but Ev Williams and Biz Stone do not seem to have much of a technical background. They made this clear in the interview, and there’s nothing wrong with this, assuming they have the technical staff to handle it.
Today on the Twitter development mailing list something was made apparent – experienced developers and businesses on the Twitter development mailing list cannot trust the architecture of the API that runs on Twitter. Just yesterday, a crucial feature of the API which allowed the retrieval of an individual’s friends and all of those friends’ timelines was removed from the Twitter API.
About 1 week ago, Alex Payne, the developer Biz and Ev kept referring to in the interview yesterday as having a lead role in the development, announced on the developer mailing list that this feature was going to be removed and asked if anyone was using it. With only about 5% of the applications saying they needed it, Twitter removed the method Thursday with just a notification on the developer mailing list and about 8 hours notice, no other notification elsewhere or warning that it was happening at that point.
All of the sudden, application developers everywhere were saying they couldn’t run their applications because of this change. These were applications such as Hahlo, Twitterati, Twibble, and Gridjit. What’s the issue here?
The issue is Twitter isn’t communicating effectively. We addressed this yesterday – I think they realize it, but I want to reiterate it. I can’t help but wonder if the experience is even there to be able to communicate effectively. I’ve worked as a developer in several publicly traded companies, one of them a Fortune 40, and some of the decisions the Twitter development staff have made would have gotten me fired at previous employers I have worked for. Where is the experience, and how can I, as a business and developer using Twitter trust them to build something on top of? I want to see where the experience is before I build any more on top of the Twitter API – does the Twitter staff have LinkedIn profiles?
Now, I’m not trying to criticize any individual at Twitter – I want to think they have the experience necessary to handle this, but I’d prefer they not pull the wool over our eyes if there is not enough experience at Twitter to handle the API I am trying to build a business off of. I know for a fact there are many smarter people using the API that could help analyze the experience if they need that help, but we need Twitter to communicate with us and let us help them out. Because businesses are being built on the API we want to see them succeed (I’m writing this as I wear my “Wearing my Twitter Shirt” I got from them yesterday). I think, as they said in the interview yesterday, while it could take months to get things in place, we, as businesses and developers could help them out if they just let us and communicate properly with us.
The questions I asked yesterday were centered around the developer and how we could help them. They told us to communicate with them. I really don’t know how we can communicate effectively with Twitter if they can’t be open to us back. I even posted this on the mailing list this morning, and received absolutely no response. As a Twitter API developer and business owner, I don’t know how much longer I can keep my Apps on Twitter. I know many others share the same frustration, and once the Apps begin leaving, so will the users.
I think, and hope, based on the interview yesterday, that Twitter understands this. I’m optimistic they do. However, we need an open communication channel, consolidated, and the experience to know how to manage that channel effectively with the API, or new opportunities are going to arise very quickly wich developers will leave to.
UPDATE: It appears that Twitter has a pretty experienced crew, per their recent blog post. Again, you still have to keep in mind that it may take time to fix the problems that are already there – is it worth the wait?
Discover more from Stay N Alive
Subscribe to get the latest posts sent to your email.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
no, but will do. thanks.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
They say they know how to fix it, and based on their latest blog post, they
seem to have the expertise to do it. With mistakes like yesterday's though,
I still wonder what's going on.
I just wrote the other day about anyone who relies on an API they don't control as a critical part of their business or app are idealistic (and maybe even foolish to a degree). APIs that are developed by larger companies (Yahoo!, Amazon, etc.) who are just extending an existing infrastructure are of course reasonably reliable enough that many people have had great successes building on those APIs. A small company like Twitter however can't be trusted to be anything more than a toy. A toy that has been very useful and changed the way many people and companies communicate, but still just a toy.
naterkane I agree and that's why they're under the gun. People are under
the impression they're much bigger than they are when in reality they don't
have the infrastructure to handle their popularity.
I'm afraid I didn't understand a single thing written in this article. What is it you are trying to say, in layman's terms?
it just has to do with taking a reactive instead of proactive approach to development.
moving their api to a cloud (amazon's or someone else's) would relieve a lot of their stress. it's difficult to stress-test any application or api, especially when it's setup to have so many different points of I/O.
this is the post i was talking about in my last comment. it's a bit more of a rant than anything else, but i'm just getting frustrated by all of the content-less noise that people are generating around what is going on with Twitter. http://www.naterkane.com/blog/2008/05/29/a-twee…
Brent, in layman's terms, be very careful relying on Twitter as your main
underlying business model. They have admitted and shown their architecture
is not ready for it.
right on. i can dig that.
lately I have been getting this fun little popup asking me to log my username and password AFTER I have logged in, and mostly when I go to the Replies section. I click Cancel, and it goes away… for a few minutes. Any idea what it is? http://www.flickr.com/photos/mopedronin/2540736… Besides 'annoying' I mean.
And 'Twitter is over capacity'… >.>
Brent, I'm not sure what that is – have you tried submitting a request over
at Get Satisfaction? (getsatisfaction.com/twitter)
no, but will do. thanks.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
They say they know how to fix it, and based on their latest blog post, they
seem to have the expertise to do it. With mistakes like yesterday's though,
I still wonder what's going on.
it just has to do with taking a reactive instead of proactive approach to development.
moving their api to a cloud (amazon's or someone else's) would relieve a lot of their stress. it's difficult to stress-test any application or api, especially when it's setup to have so many different points of I/O.
this is the post i was talking about in my last comment. it's a bit more of a rant than anything else, but i'm just getting frustrated by all of the content-less noise that people are generating around what is going on with Twitter. http://www.naterkane.com/blog/2008/05/29/a-twee…
[…] you can follow the loooong discussion in the twitter dev group. Here are some comments by staynalive. The good news: twibble mobile reached Version 0.7.9! It has some bugfixes and should be resistant […]
[…] […]
tramadol…
what is tramadol. buy tramadol online. tramadol online. …
[…] […]
tramadol…
what is tramadol. buy tramadol online. tramadol online. …
naterkane I agree and that's why they're under the gun. People are under
the impression they're much bigger than they are when in reality they don't
have the infrastructure to handle their popularity.
no, but will do. thanks.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.
I wonder if the Twitter staff have commissioned an externally-evaluated code audit on both the core processes and the API calls because from the outside looking in, I doubt that any amount of new hardware will boost Twitter reliability.