As a Twitter developer, I’ve had a fair amount of experience with their API and thought that I might express how I think Twitter could help developers. Twitter interacts with the community, requesting feedback on new features, helping developers, and generally letting us know what is happening with API status at Twitter Development Talk. Twitter also offers API Announce to let developers know what is happening with the API. If you’ve been watching, the Twitter API team has been growing and evolving in a positive direction to help developers. These are all good signs that indicate a continued dedicated effort toward improving their API, but there are still pain points that I’ll address in the following paragraphs, including testing, API availability, and roadmap.
One of the first things I noticed when coding against the Twitter API was the glaring absence of a test environment. That means all coding and testing must be done against the production Twitter environment. As a professional software engineer, this ripples against the grain of common sense and is still something that causes me hesitation any time I test. The current answer is to set up a dummy account on Twitter to test with. However, that still leaves me wondering about things like usage policies and the like. For example, what if I wrote a test that slammed Twitter with tons of new requests. Would an unfortunate result in my programming and testing behavior make me a hacker, a spammer, or just an idiot that didn’t desk-check his development code; and what would be the response from the folks at Twitter evaluating the results of my actions? To fix the problem with no test environment, Twitter should offer an endpoint for just testing and let developers establish test accounts.
The way Twitter is handling release of the latest API’s is to give a selected set of users access to a feature and a selected set of developers access to the associated API. This is normal with Beta testing and developers who weren’t included should normally not be concerned. The problem occurs when the feature is given to the general public and the vast majority of developers are caught unprepared to support users. Two features that follow this pattern are Lists and Retweets. I’ll give Twitter credit for publishing specs, which at least gave some developers the ability to write code to the spec, but it doesn’t solve the problem. The problem is that the situation can result in users frustrated because their 3rd party applications are slow in providing support for the new features. Just an observation, but those users could always dump their current 3rd party vendor and run to a 3rd party vendor that was included in Twitters beta program for early API access. It would be helpful if Twitter released new APIs to the developer community before releasing the new Web site feature to the general public.
The Roadmap could be much better. The problems are that it is too tactical, lacks important information, and is useless for planning. If there were a good thing I could say about the roadmap is that it seems to be fairly well-organized and shows some of the items they have considered for implementation; although some items, such as the test environment plans discussed earlier, are nearly a year old. Looking at the items on the list, most subject areas look like down-in-the weeds topics that are important in themselves, but provide no strategic direction or vision on where the API is headed. For example, one of the items is named “Return User object on end_session method”, which is important; but is important on only that part of the API. These tactical items are already on the bug list and Twitter could enhance the developer experience with a separate priority list for bugs; which might be entirely possible with the existing Web site tools. Another problem is that the Roadmap doesn’t include information about upcoming APIs, which I believe is more appropriate content. For example, what if the roadmap had included significant API features such as Retweets, Lists, or Geotracking, which are the type of things that should be included in a roadmap? The purpose of the roadmap should be for developers to look at what Twitter has planned and prepare accordingly. The Twitter roadmap has no information on priorities or planned implementation. If 3rd party applications want to plan for future growth, they can’t use the roadmap for any long term plans because Twitter publishes previously unannounced APIs before items on the roadmap are addressed. The roadmap would be much more useful if it concentrated on strategic initiatives that included upcoming APIs with at least some indication of when the API will be implemented.
As Twitter continues to grow and 3rd party libraries and applications glom on, Twiiter should nurture the developer ecosystem they brought into being. A testing platform is long overdue, proper release of APIs should be fair, and the roadmap should support planning and vision rather than being a hit list for heads-down coders. I’m sure you might have a favorite item to put on Twitter’s developer ToDo list, but these are the things that I’m thinking about the most.
@JoeMayo
Joe Mayo 