[badman_ting]

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]

I wonder what this mindset does for the future employability of FB people, do people really want to employ people who are (basically) reckless?

[threeseed]

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]

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.

[toyg]

Well, they can turn it around: "been there, done that, learnt lessons with the intensity of a thousand suns".