One of the more commonly used functions is getInfo(), which returns almost any piece of information from a user’s profile page; gender being one of them. The value returned for gender is either “Male” or “Female,” which is fine – but they are localized in the user’s language. So does this mean you have to check for “Female” if the user is using Facebook in English and “Weiblich” if the user chose German? Yes. It also means you have to check for imaginary languages. “Lass” is what you get if the user has his language preferences set to Pirate (English). You can see the headache this causes a developer if they are asked to report on the demographic of users of your app.

Another problem plaguing developers is the lack of organization for the documentation. The bulk of documentation exists on their developer wiki. This works well enough if you know exactly what you’re looking for, but if you don’t know the name of a function you’re better off using Google. A wiki format is more conducive to separate pages. So for a new developer stumbling on to the wiki, aside from a few copy-paste tutorials, there is no clear path of where to go. Only recently, with the release of their Javascript SDK, have they created a concise page containing documentation. Facebook officially supports 5 client libraries. For some of the libraries, documentation exists on the wiki and is shared amongst one another. All of the functions are typically the same for every language, so only one wiki page exists. PHP as well as Connect for the iPhone use the wiki pages, while the ActionScript library documentation is housed on Google code. This is because a lot of these libraries were contributed by the community and not officially created by Facebook, but this can be a large annoyance if you automatically assume that the function you’re using in a particular language is described by the wiki. Forcing people to scour multiple sites and forums for documentation is never a good idea if you are trying to build a good developer community around your platform.

The Facebook Platform status usually states “Facebook Platform is Healthy”. Occasionally it displays messages about performance issues, but that doesn’t help you much. Chances are, if you’re looking at Facebook platform status, you noticed the performance issues on your application. Looking at the “Average API Response Time” and “Error Count” doesn’t reveal much because there are no units on the y-axis. However looking at Developer Updates and Top Life Platform Bugs mights shed a light on the current status of Facebook. So what is the state of Facebook? Developer Update states they are changing profile picture sizes. So everyone who ever uses a profile picture in their application should go and double check that the new sizes will work. Existing Facebook applications constantly need to be updated to simply work. The bug list is as expected; there are a few major bugs, e.g. suggest to friends does not work (opened 29 December). And less critical but still annoying ones, e.g. request-form action opens a new window (opened 07 April 2009). The platform is in a state of constant flux with backwards incompatible updates being released and bugs for old features being introduced. If you create a Facebook app, you can’t just “set it and forget it.” You must monitor for changes to the platform and update your app as needed. You must also expect that there will be periods where your app won’t operate due to internal problems with Facebook’s system.

So where does this developer hell leave us? It actually promises a brighter future. The reason the API is broken is due to Facebook constantly working on it and bringing more enhancements to users and developers. They are rolling out new features such as allowing applications to gather a user’s email if given permission and giving more control to users over their privacy settings. Yes the platform is immature, but it’s certainly not stagnant. So what can a developer do to make things smoother? There are certainly enough complaints out there, so that path won’t lead anywhere. Trying to write more on the wiki and help the community won’t be very fruitful, because the API changes quickly enough that your notes may be soon outdated. In fact, the abundance of notes like this on the wiki makes it confusing as to who is right. Here are some suggestions for developers to cope with the situation:

1. Manage your client’s expectations. Make them aware that Facebook encounters issues periodically and this is out of your control. Give them the link to the Platform Live Status page so they can check that before coming screaming at you.
2. Subscribe to the Platform Live Status Feed, Developers News Feed, and Facebook Pages Notes. This way you should always be aware of a problem or an upcoming change before your client. The feeds are available via RSS or email except for the Pages Notes which seems to only be RSS.
3. Stay up to date with the Developer Roadmap in the wiki. You can create an account in the wiki and “watch” this page to get notified of changes.
4. If the client library you’re using has a svn repository, you can check the log to read about changes. For example, this command works for the PHP library – svn log -v http://svn.facebook.com/svnroot/platform/clients/php/trunk/. The ActionScript library on Google code page has a web interface for browsing changes – http://code.google.com/p/facebook-actionscript-api/source/list. There are some tools for automatically getting notified of an update to the code: SVN-Monitor, CommitMonitor, and SVN Notifier. Unfortunately, these are all Windows programs. Leave a comment if you know of one for Mac or Linux (yes, we know you can easily write a cron script to do it

In summary, at this stage if someone says “We want to do this and that with Facebook,” the best thing to do is say “I can try but I make no guarantees” instead of “Sure, it’s totally possible” because with Facebook you never know if what is available today will be still available by the time your application is ready to launch.