Dealing with multiple APIs

I had a conversation with Tack, one of the lead web developers at Traction, last week about APIs. I had this theory that interactive agencies were facing a new problem I was calling "API fatigue." From my vantage point, it seems like there is a new API every week for our engineering team to learn: First there was ActionScript, then Facebook API, now OpenSocial, iPhone, Android, Salesforce.com, YouTube API, Amazon, API, Twitter API... the list goes on and on.

Surprisingly, he was dismissive about my concern. Here's an email he sent me following our conversation:

I was thinking about this a bit more since out discussion the other day. I don't think it [API fatigue] exists, at least in its semantic meaning. Programmers are constantly exposed to new API's throughout their careers. It would be akin to talking about plumbers getting "wrench fatigue." Every time we do something new, which should be constant in a fulfilling career, we learn parts of a new API or learn more about one we're already familiar with.

I think what you may be more wary of is the seeming explosion of new APIs available. And, the work of keeping up with it all that goes along with such growth.

This would have been a big hill to climb before wiki's and blogs. It used to be that in order to evaluate and learn a new API you'd have to take a blind leap into a book on the subject (after doing the work of discovering the subject) hoping the book was decent. And you'd have to go through that cycle every time you wanted to learn some new tricks. Now the work of discovery can be done passively via RSS. Blogs like ajaxian for instance are constantly reporting on developments in AJAX that you can scan via RSS and bookmark for later. And wikis allow people to outline the strengths and weaknesses of a new API along with collectively documenting how to get the most out of it. You buy the book after you've decided it's a worthwhile skill to develop.

As far as how to keep companies and teams abreast of the state of the art, I think that it's important to factor in time for developers to do a little research and share what they've learned with the rest of the team. This could be in the form of making allowances for side projects (like Google's 20% time or just allowing developers to pursue hobby development in slow times) and scheduling time for teams to gather socially. Like a team lunch or happy hour. This encourages developers to research what they're passionate about and think outside of their workaday box. And, share the roadblocks they've faced with each other so that the others can offer suggestions they'd never have thought of on their own.

The surge in innovation in this space is built on the tools you need to keep up with it. Group discovery and the knowledge of crowds. Nurture that and you may get both a great team and great innovations.

There you have it, boys and girls. The cure for API Fatigue Syndrome: the wisdom of crowds and a pint of beer.