We began building Facebook applications a few weeks prior to the launch of the new platform. One of our clients was a launch partner. Part of the experience has been learning to react to the strengths and weaknesses of Facebook’s development process. I’ve commented to friends and posted my thoughts in the developer forums but today I found another developer who has experienced the pain of developing applications on the Facebook Platform.

Facebook’s platform has been much more fluid (to put it nicely) than most public API’s (Application Programming Interface). It has changed frequently, at times in seemingly arbitrary ways. One time the name of a parameter was changed to a synonym. I appreciate accuracy when naming, but once your API is released you probably shouldn’t change names merely because of preference. I don’t want to list all of the issues that I’ve encountered. I simply want to whole-heartedly affirm Shannon Whitley’s experience.

However, as sympathetic as I am to Shannon’s concerns, I’m not sure that these problems are merely a flaw with Facebook and their processes. I’m suspicious they may be the sign of a broader rift in the world of software development. This rift exists between those systems that can and therefore will tolerate downtime and bugs and those that can’t and won’t. However, the software process wars that are raging don’t seem to acknowledge this rift and as a result all focus on meeting the requirements of the most stringent systems. Agile software processes seem to accommodate projects with less stringent requirements, but they too still attempt to address the requirements of non failure tolerant systems. I don’t want to advocate Facebook’s apparently nonchalant approach to its release cycle, but I think the context in which Facebook is developing may be doing as much to drive its process as anything else.

Here are some observations that seem to give Facebook more freedom to continue developing as they are:

• With the advent of Web applications the rules for delivering software changed. Prior to this time bugs in a product were much more difficult and costly to correct once the application had been shipped. One of the benefits of a web application is the extremely simple distribution model. Copy the code to the server. Distributed. Because of the new model the effort required to correct any given bug is often minimal.
• Many applications just don’t matter. What I mean is that they are simply not mission critical to anyone, anywhere. Facebook is an example of this type of application. If it goes down for five or ten minutes, who cares? Sure some people will be a little inconvenienced but governments will not collapse, no missiles will be launched. 5 Nines (the nearly perfect uptime requirements of core systems) is not important in this world.
• Users don’t get as upset about web application outages. Sure it’s nicer if they aren’t out. And if they’re out too long, I may just look for something else. But hey, it’s free after all. And, I’ve got a ton of other stuff out here to mess with. And, I’m not really sure if it is the web site or my internet anyway. They tend to go out a lot (except on Apple computers which use Airport rather than an internet) and I’m pretty sure the cable company has something to do with it. Sometimes ignorance is bliss for the enlightened too.

From a third-party developer perspective all of this is really no fun. You find yourself monitoring blogs and forums watching for changes. And, your clean development process gets all screwed up. But maybe it is just the reality of the fast moving, competitive throw-away web that we’re building on top of. Thankfully Facebook isn’t responsible for developing database management systems or operating systems. But, I have a feeling, if they were they would probably go about it in a completely different way.