6 ms·

Facebook made three clear mistakes: - Not building in a revenue model into their platform, like Apple did with iOS. This is so stupid. - Not creating clear a

Facebook made three clear mistakes: - Not building in a revenue model into their platform, like Apple did with iOS. This is so stupid. - Not creating clear and consistent access rules around the social graph and notifications, with the ability to throttle down (but not altogether remove) access for offenders. They could even automate the throttling based on user feedback (in the form of clicks). - Breaking things constantly. My brief, frustrating experience maintaining a Facebook application consisted of the app breaking every two weeks as Facebook somewhat randomly changed things without warning. All of these were pretty foreseeable.

rhizome 13y ago
Breaking things constantly. Apps aside, the proportion of basic wall pageloads that hang due to, I'm assuming, some javascript complexity approaches 100%.
Eduard 13y ago
My brief, frustrating experience maintaining a Facebook application consisted of the app breaking every two weeks as Facebook somewhat randomly changed things without warning. When did you have this experience? How long ago is it? For now quite some time, Facebook has been open with upcoming "breaking changes", giving Facebook App developers three months in advance to adapt accordingly: https://developers.facebook.com/roadmap/change-policy/ https://developers.facebook.com/roadmap/change-policy/
- mratzloff 13y ago
  2007-2008.
- ThomPete 13y ago
  I built https://apps.facebook.com/pinviewer/ https://apps.facebook.com/pinviewer/ in 2012 and even up to there, FB changed things all the time without any warning.
- btipling 13y ago
  2008-2009 I dealt with the Facebook API and they often broke things. The breaking changes notifications have improved things, but they still break things. Their insight analytics was broken for about a year. They just don't seem to care about their API.
  - vinbreau 13y ago
    Agreed. I've been working with their API for the last 2 years. When it does break it can take forever to get a response. I work for a Facebook preferred developer so we have an extra channel for getting bug feedback. If we weren't a preferred developer, we would have had API bugs go unaddressed for months. Sure there were warnings about some changes, but sometimes major changes occurred that we did not see coming and had to scramble to figure out workarounds.
- ripter 13y ago
  How about two weeks ago? They fail to mention in their list of breaking changes that the id format would changed from profileId_postId_commentId to profileId:postId:commentIdThatMightContainUnderscores Except that not all posts follow the new ID format. Not all new posts even follow it. It's now a mix of the two.
  - rmc 13y ago
    Here here. You can't trust the Facebook docs to be complete. I have numerous comments in our codebase of "Facebook API docs are wrong, it's actually X..."
    - ripter 13y ago
      Somewhere on the site they actually tell you to use Stackoverflow because it's more up to date.
      - chrisblizzard 13y ago
        Do you have an example?
    - return0 13y ago
      It's odd that they chose stackoverflow for their support system, because most of the answered questions there are way obsolete by now.
      - wwweston 13y ago
        They chose StackOverflow for their support system at one point. At one point, they've also chosen a web forum, a wiki lots of devs bought into (but which they later entirely blew away and replaced with Bing searches of their site), and probably a half-dozen attempts at official on-site docs. When I saw they'd offloaded to StackOverflow, I thought that was an idea that had some promise, but the big question in my mind was how long until it reached the critical mass where it would consist of more out-of-date answers than current ones. And what they'd do when it does. The answer, of course, is likely move fast and break something, and heaven help the people who had the idea of building something on top of their quicksand.
- return0 13y ago
  Preannounced or not, the fact is it's a dizzying rate for independent developers to catch up with.
badman_ting 13y ago
Even though it generally drives me nuts, the "move fast and break things" mindset can work in some situations. Building a platform for others to rely upon is not one of them. I never understood why they repeatedly broke their platform so much, unless they honestly did not care how it affected those downstream. But if they didn't care, why even build a platform? Even the most cowboy of coders can see why always breaking others is bad. Baffling.
- colinhowe 13y ago
  I wonder what this mindset does for the future employability of FB people, do people really want to employ people who are (basically) reckless?
  - toyg 13y ago
    Well, they can turn it around: "been there, done that, learnt lessons with the intensity of a thousand suns".
  - threeseed 13y ago
    I don't know if you are a developer or not. But the entire industry is moving towards the Facebook model i.e. those people would be highly desired in many places. The "theory" is that developers can't be reckless because all of the automated testing that goes on before anything is put into production.
    - cube13 13y ago
      Not if you're making APIs, which is essentially what the entire platform is. The "Move Fast and Break Things" attitude is fine when you're releasing a complete product. Look at Twitter or GMail. Google and Twitter change their interfaces pretty much constantly, and outside of a few hours or days of grumbling, pretty much everyone goes back to using the services. But if you're providing functionality that other people are coding against, it's a cardinal sin to break your API without warning everyone. When making API's, slower and more monolithic releases is often a better approach. It not only gives your teams time to develop and test the features, but it also gives downstream users of your API time to absorb the changes.
johnward 13y ago
Revenue stream was a pretty big miss. Devs weren't offered a share of the facebook ads income for views on their apps and they had no way to fund paid apps. So 3rd parties came in to cover the gap and then Facebook didn't like it so they started banning them or trying to force their own half baked solutions.
prostoalex 13y ago
>> - Not building in a revenue model into their platform, like Apple did with iOS. This is so stupid. It was not completely obvious in 2007 that in-app virtual item transactions were to stay. Facebook itself was playing around with virtual gifts, but convincing users to pull out their credit card on a social network was novel. It was pretty hard to predict specific monetization pattern - iLike looked into ticket-selling, Visual Bookshelf would do affiliate links to Amazon, Slide's apps would monetize through standard banner ads (and later video ads), Zynga was not even around at the time.
- mratzloff 13y ago
  Was it that hard? "If you make money on our platform, you need to give us a percentage," seems sort of like an obvious monetization strategy. Otherwise, what's the point of building the platform?
  - prostoalex 13y ago
    Most of the apps at the time optimized for pageviews and monetized through DoubleClick, AdSense and other third-party ad networks, so there was non-trivial task of proving that "making money" was happening, followed by further non-trivial task of actually collecting such revenue from all of the jurisdictions. >> Otherwise, what's the point of building the platform? Facebook displays its own ads on application canvas pages. Therefore higher engagement with apps => higher pageviews => higher earnings.
prometheuspk 13y ago
I apologise for my ignorance, but can you elaborate on how the iOS has a revenue model? Are you talking about the Apple Store?
- wisty 13y ago
  Apple's App store has purchases, in app purchases, and an ad network baked in. Granted, they've had longer to think it through.

rhizome 13y ago

Breaking things constantly. Apps aside, the proportion of basic wall pageloads that hang due to, I'm assuming, some javascript complexity approaches 100%.

Eduard 13y ago

My brief, frustrating experience maintaining a Facebook application consisted of the app breaking every two weeks as Facebook somewhat randomly changed things without warning. When did you have this experience? How long ago is it? For now quite some time, Facebook has been open with upcoming "breaking changes", giving Facebook App developers three months in advance to adapt accordingly: https://developers.facebook.com/roadmap/change-policy/ https://developers.facebook.com/roadmap/change-policy/

mratzloff 13y ago
2007-2008.
ThomPete 13y ago
I built https://apps.facebook.com/pinviewer/ https://apps.facebook.com/pinviewer/ in 2012 and even up to there, FB changed things all the time without any warning.
btipling 13y ago
2008-2009 I dealt with the Facebook API and they often broke things. The breaking changes notifications have improved things, but they still break things. Their insight analytics was broken for about a year. They just don't seem to care about their API.
- vinbreau 13y ago
  Agreed. I've been working with their API for the last 2 years. When it does break it can take forever to get a response. I work for a Facebook preferred developer so we have an extra channel for getting bug feedback. If we weren't a preferred developer, we would have had API bugs go unaddressed for months. Sure there were warnings about some changes, but sometimes major changes occurred that we did not see coming and had to scramble to figure out workarounds.
ripter 13y ago
How about two weeks ago? They fail to mention in their list of breaking changes that the id format would changed from profileId_postId_commentId to profileId:postId:commentIdThatMightContainUnderscores Except that not all posts follow the new ID format. Not all new posts even follow it. It's now a mix of the two.
- rmc 13y ago
  Here here. You can't trust the Facebook docs to be complete. I have numerous comments in our codebase of "Facebook API docs are wrong, it's actually X..."
  - ripter 13y ago
    Somewhere on the site they actually tell you to use Stackoverflow because it's more up to date.
    - chrisblizzard 13y ago
      Do you have an example?
  - return0 13y ago
    It's odd that they chose stackoverflow for their support system, because most of the answered questions there are way obsolete by now.
    - wwweston 13y ago
      They chose StackOverflow for their support system at one point. At one point, they've also chosen a web forum, a wiki lots of devs bought into (but which they later entirely blew away and replaced with Bing searches of their site), and probably a half-dozen attempts at official on-site docs. When I saw they'd offloaded to StackOverflow, I thought that was an idea that had some promise, but the big question in my mind was how long until it reached the critical mass where it would consist of more out-of-date answers than current ones. And what they'd do when it does. The answer, of course, is likely move fast and break something, and heaven help the people who had the idea of building something on top of their quicksand.
return0 13y ago
Preannounced or not, the fact is it's a dizzying rate for independent developers to catch up with.

badman_ting 13y ago

Even though it generally drives me nuts, the "move fast and break things" mindset can work in some situations. Building a platform for others to rely upon is not one of them. I never understood why they repeatedly broke their platform so much, unless they honestly did not care how it affected those downstream. But if they didn't care, why even build a platform? Even the most cowboy of coders can see why always breaking others is bad. Baffling.

colinhowe 13y ago
I wonder what this mindset does for the future employability of FB people, do people really want to employ people who are (basically) reckless?
- toyg 13y ago
  Well, they can turn it around: "been there, done that, learnt lessons with the intensity of a thousand suns".
- threeseed 13y ago
  I don't know if you are a developer or not. But the entire industry is moving towards the Facebook model i.e. those people would be highly desired in many places. The "theory" is that developers can't be reckless because all of the automated testing that goes on before anything is put into production.
  - cube13 13y ago
    Not if you're making APIs, which is essentially what the entire platform is. The "Move Fast and Break Things" attitude is fine when you're releasing a complete product. Look at Twitter or GMail. Google and Twitter change their interfaces pretty much constantly, and outside of a few hours or days of grumbling, pretty much everyone goes back to using the services. But if you're providing functionality that other people are coding against, it's a cardinal sin to break your API without warning everyone. When making API's, slower and more monolithic releases is often a better approach. It not only gives your teams time to develop and test the features, but it also gives downstream users of your API time to absorb the changes.

johnward 13y ago

Revenue stream was a pretty big miss. Devs weren't offered a share of the facebook ads income for views on their apps and they had no way to fund paid apps. So 3rd parties came in to cover the gap and then Facebook didn't like it so they started banning them or trying to force their own half baked solutions.

prostoalex 13y ago

>> - Not building in a revenue model into their platform, like Apple did with iOS. This is so stupid. It was not completely obvious in 2007 that in-app virtual item transactions were to stay. Facebook itself was playing around with virtual gifts, but convincing users to pull out their credit card on a social network was novel. It was pretty hard to predict specific monetization pattern - iLike looked into ticket-selling, Visual Bookshelf would do affiliate links to Amazon, Slide's apps would monetize through standard banner ads (and later video ads), Zynga was not even around at the time.

mratzloff 13y ago
Was it that hard? "If you make money on our platform, you need to give us a percentage," seems sort of like an obvious monetization strategy. Otherwise, what's the point of building the platform?
- prostoalex 13y ago
  Most of the apps at the time optimized for pageviews and monetized through DoubleClick, AdSense and other third-party ad networks, so there was non-trivial task of proving that "making money" was happening, followed by further non-trivial task of actually collecting such revenue from all of the jurisdictions. >> Otherwise, what's the point of building the platform? Facebook displays its own ads on application canvas pages. Therefore higher engagement with apps => higher pageviews => higher earnings.

prometheuspk 13y ago

I apologise for my ignorance, but can you elaborate on how the iOS has a revenue model? Are you talking about the Apple Store?

wisty 13y ago
Apple's App store has purchases, in app purchases, and an ad network baked in. Granted, they've had longer to think it through.