It’s Time For Facebook to Grow Up
There’s a lot to like about the Facebook development platform. I’ve been having fun working with the framework and discovering its power and its limitations. One of the biggest issues, however, stems not from the development platform itself, but the seemingly immature support environment behind it.
This post may come off as a tad condescending to the folks at Facebook. I apologize in advance if you are already implementing these best practices. However, from the outside, it looks to me as though there is some room for improvement in your development methodology.
The two notifications below from the Facebook Developers’ Site are examples of what I’ve seen in the past two weeks. One notice refers to a bug that was introduced into a core feature of the platform. When the bug was fixed, all Facebook could manage was a weak, “…sorry for the bug,” as external developers scrambled to appease their complaining users. The second example caused me to look for a glass of water so that I could spit its contents into the air in shock. “You’re testing a new feature in production! Let us know if something doesn’t work!?!”
Aug 11, 2007 10:33pm
fb:refs couldn’t be updated for a number of hours earlier today. this should be resolved now. sorry for the bug.
testing a new FBML parser
Aug 10, 2007 12:20pm
We’ll be testing a new FBML parser on a small percentage of pages shortly. if you observe quirky behavior (or your users observe quirky behavior) that you can’t reproduce, please let us know. the new FBML parser is faster so your canvas pages should load faster for users once we can roll this out completely.
Maybe this was acceptable to Facebook before they opened up the API to external developers. I can’t believe you can have thousands of users and have this be acceptable, but that’s Facebook’s choice. Now, however, these mistakes and mishaps are affecting hundreds of developers and thousands of users. Individual developers and companies are sinking valuable time and money into the Facebook platform. Random bugs and preventable breakage is just not acceptable when you have other people relying on your product.
I’ve been supporting large information systems for a number of years. Yes, I’ve made mistakes and introduced bad code into production. Have I done it every week (every day) like Facebook has? Well, I wouldn’t have a job if I did.
I’d like to make a few suggestions to the Facebook development team. Again, I’m a big fan of your work, but there’s obviously something wrong with your current approach:
- Slow Down – Yes, new cool features are important, but not at the expense of stability and reliability. Slow down with the changes, test your changes thoroughly, and focus on reducing errors before they get pushed out to the users.
- Maintain Development Tiers – At the very least, you should have a Development environment, a QA environment, and a Production environment. It might even be helpful to have one or two other environments depending on your process. Use a tiered-approach to development. Code changes should only be introduced in the Dev environment and then migrated up from there. Never allow developers to make changes to any environment except the lowest-level Dev environment.
- Create A Developer’s Sandbox – If you have new code that you’d like to introduce into a production-like environment, create a Sandbox where you can get help from external developers. Setup a trouble ticket system whereby we can give you feedback. We’d be more than happy to help you test out your new code and ensure that it doesn’t break the code in our applications. This has worked very well for the open source community where nightly builds are tested by external users.
- Beef Up Your QA Efforts – You’re too big (and important) not to have a separate QA department. The QA department should have a standard set of scripted tests that are run on every build. These tests should uncover simple things like bugs that break <fb:ref>.
- Change Your Mindset – When you opened up your platform to external developers, you changed your mission. You are no longer just responsible for your own code. Every change you make affects hundreds of developers. Your mission is to maintain stability in your framework. You no longer have the ability to try something, hope it works, and then apologize if it doesn’t. Your developer community suffers when you don’t maintain a stable framework. We are servicing our mutual customers, and we receive the complaints when your code breaks.
I like the work that you’re doing, Facebook. I want to support you, and I want to build on your platform. Please don’t let these poor development practices continue.
mark said,
Wrote on August 12, 2007 @ 9:45 pm
Har har,
I’ve been playing around with some app. stuff as well, mostly for ClutterMe and just hacking in general. It definitely has a *teenager* feel to it, especially judging from the support that this app stuff gets.
Shannon Whitley said,
Wrote on August 12, 2007 @ 10:17 pm
Mark,
Good luck with your launch!
I read about your Wii purchase on the blog. We just purchased a Wii last week (for the kids) and I love it. Wii boxing is actually a great workout.
It’s time for Facebook to grow up at bunnyhero dev said,
Wrote on August 14, 2007 @ 1:10 pm
[...] Excellent post by Shannon Whitley about how Facebook is managing their app platform. [...]
Ryan said,
Wrote on August 15, 2007 @ 9:45 am
I completely agree. My team has been developing a large-scale app since Facebook opened their platform, and our biggest source of frustration has been from the FB developers themselves. Stuff like this just shows a lack of respect for their development community. A lot of this stems from their arrogance, and it’s a major problem.
There’s a few other examples I can think of too (invitation limits? spamminess indiator? random brokenness all over the place?). Thanks, facebook, for deigning to allow us to develop for your platform. Oh, and sorry if we expect you to treat us like professionals (and act like it).
TRUE - We design things and make software, like our interactive digital signage system called Media Grove said,
Wrote on August 15, 2007 @ 9:54 am
[...] 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’s experience. [...]
Dave said,
Wrote on August 15, 2007 @ 10:25 am
Great post. Just by reading through the Facebook Developer Discussions, you can find people having other problems caused by Facebook being arrogant and unhelpful to developers. They include:
* Developers who submit their completed apps only to to be rejected for it being “unfinished”, with no further explanation.
* A user whose app had a bug during development that caused extra notifications to be sent out. His app was blocked for being too spammy.
* Many users have had their notifications (or the apps themselves blocked) for being too “spammy” or going over the invite limit. However, Facebook never gives a concrete definition of spamminess, or the exact threshold for invites.
* When a user creates an app, they cannot add another admin or give someone else the admin status. This means that the app will be stuck with that developer even if they leave the company. You can’t create a fake account to own the app, since that’s against Facebook’s TOS. So basically, I guess you’d have to have the founder of the company create the application, then give you their password to develop it!
I appreciate what Facebook is trying to do with the Platform, but I think they need to start being more open with the development community, and focus on fixing existing problems before continuing to add new features.
Shannon Whitley said,
Wrote on August 16, 2007 @ 9:18 pm
Thanks for the comments everyone. I’m just about done with Facebook. The experience just keeps going downhill.
Ryan Merket said,
Wrote on August 18, 2007 @ 10:01 am
Wow, do you want some cheese with the whine?
Seriously, this is the first time any website has every opened the doors to developers to develop directly on a launched platform with over 50 million users…
They are doing the best they can (and a damn good job too).
Shannon Whitley said,
Wrote on August 18, 2007 @ 7:41 pm
Please, Ryan. Google, Yahoo, and many other huge sites have had APIs available for a long time. I’ve implemented several Google API solutions without one hiccup. The only unique thing with Facebook is that you can affect the user interface, but what does that have to do with the stability of a platform?
The problem is that, unlike Google, Facebook is making changes to their site in the middle of the day, updating code without making it transparent to the users, and generally not handling code updates very well.
All they need is someone to monitor their release cycles better. These are just suggestions — constructive criticism, if you will. However, if the offer still stands, I prefer well-aged, medium cheddar.
Kurt G said,
Wrote on August 21, 2007 @ 6:30 am
Although I appreciate your frustration. I would could FB a little slack.
To your points:
1. Slow Down: Most of their current releases are not new features, but changes to prevent unwanted behavior or improvements to keep up with the exponential load increase on certain components (like FBML parser or restserver) caused by us.
2. Maintain development tiers: They most certainly do have multiple tiers. I have seen the links to their dev/test version. I just suspect it is hard to simulate the real time load they see, which may well be far more than the APIs you mentioned.
3. Sandbox: They seem to have the ability to enable certain functionality on a developer by developer basis to do invite only testing. A full sandbox might be difficult as you wouldn’t have access to your ‘social graph’.
4. Beef up QA: Seconded. You are spot on there. In the mean time, it is up to us to diligently report the issues we find and work with the Wiki to help guide the platform team.
5. The fact that we have to answer to our own customers now is a tough one. We have to apologize for issues out of our control. I think FB could do a better job of communicating the ‘oops’ to the broader audience, so they know it wasn’t our fault. Having said that, as per the above comments, there are many areas they need to change frequently just to keep up.
Shannon Whitley said,
Wrote on August 21, 2007 @ 10:12 am
Thanks, Kurt.
My frustration has waned on this topic. It isn’t my style to complain a lot, but there just seemed to be a lot of rookie mistakes going on. I’m looking forward to moving forward and getting through these rough spots.