Lots of people have pretty sensitive data within facebook with very granular privacy settings. When I read this attitude from facebook, it scares the shit out of me.
I'd love to hear more about why I shouldn't fear that their "Show this post to only x group of people" feature will break and result in everyone being able to see all my posts. What are your testing procedures for that and at what point are those kind of bugs caught?
I don't believe the lack of quality in Facebook code poses an existential threat to Facebook, and I don't believe it ever will:
(1) Facebook code is not Google code, but it is not bad code, it's just not needlessly good code. If Google is consistently buggy, anyone can switch to Bing. On the other hand, switching from Facebook is really hard. Their core services are not easily replaceable. People are willing to put up with more. Note that this is even true in the case of businesses: Facebook is horrible to develop against, but developers don't have a choice.
As the network grows, this cost will be higher, which means Facebook can throw its weight around more, not less. This is exactly opposite of the situation you predict. The only thing that can really reverse this is if there is a viable competitor, but the increased growth of Facebook makes this increasingly unlikely. It is clear, in any event, that G+ is not quite there.
(2) By maintaining a lower bar, Facebook actually has an advantage. It is a website, and can fix its product at will. Code can be deployed quickly and rolled back accordingly, making failure cheap. This means they can concentrate on things that really matter like user acquisition.
(3) Facebook does not run nuclear reactors or bank systems. There is a high incentive to switch from buggy bank systems. There is little incentive to switch from buggy social network websites.
footnotes:
[1] whatever that means
I'm arguing that facebook wants to run something even more important than a banking system. For example, Facebook wants me to share posts that are only visible to me. Such a post could contain secrets that could have huge consequences on my life and life of others' if they became public. It is pretty clear from facebook's history that each year, they want you to share more of such private data.
They started with you being able to share your drunk party pics. They are headed towards actually becoming something like PayPal. Really, facebook should behave more like a bank than just-another-social-network if it wants its users remain confident. In this respect, looking at their past success to as proof that all is well is a mistake because I am certain facebook intends to be much more than what it is five years from now.
That means a privacy or a security issue will be tackled with the utmost urgency--we would even shut down the site if we didn't have a quick fix for a security/privacy bug. However, if one of the Timeline aggregations isn't working or if a particular text box is not aligned, then we will fix it with the next release (usually in another day or half).
So it's not true that "move fast and break things" means "it's OK to introduce privacy/security holes" or even "it's OK to release shitty products". It just means we push early and push often.
Even if it took only 30 seconds to find the error and the entire site was unplugged from the web so you could fix the bug, the damage is done, it's permanent and it's devastating. Facebook is crossing the line from failures being trivial to failures being potentially catastrophic. Sad, perhaps, by the standards around here, but some people conduct their lives on Facebook -- encouraged by Facebook to do so, mind you -- and you guys are treating it a little more seriously than a hackathon, from the sounds of it.
For example, there is a layer called Gatekeeper that ensures only certain features are shown to users and that with a flick of a switch, code can be decommissioned in the event of a crash or breach.
- Accidentally opening all profiles up, causing users to have to reset them.
- Accidentally setting all photos to public, causing users to have to reset them.
- Syncing many peoples contacts to @facebook email addresses, in many cases deleting the users original contact lists
- (the last straw) - letting private messages go onto the public wall. Facebook deny's this happened, but I personally know two people (no friend of a friend business) who this has happened to. In both cases there were very private messages from their ex-partners, the kind of thing they'd take extreme alarm to if they were on their wall. Both quickly deleted all messages when it happened, rather than saving the evidence.
Move fast and break things when there's private info at stake, is not the correct way to do things. I stopped posting to facebook and am going to close my account (and move to G+, who have better quality controls), and have non-tech friends who have decided that's the way to go after the private messages thing.
However he should probably have been described as ex-Facebook, he left quite a while ago.
'Facebook engineers rave about Phabricator, describing it with glowing terms like "okay" and "mandatory".'
We're also big fans of Phabricator over here at MemSQL.
On the other hand, perhaps someone will argue that all publicity is good publicity.
Things break all the time in any company, but by understanding that frequent breakages occur, and adapting your development process to that understanding, you enable fast recovery and ultimately less breakage and greater security in the long run.
See for example: your car, your bank (not the website, the backend), the space shuttle, the Fed, anything important. Some places cannot accept the supposed fact of frequent outages and failure, and engineer for that reality instead.
I don't know how you're concluding that the hackday coding methodology creates more secure code, unless you are simply unaware of the industrial standards to which other fields' programmers are held.
However, few companies are rated on the quality of their code. Rather, most companies are rated on how well they serve their customers needs, including the vast majority of companies discussed on Hacker News.
The way to delight your customers is to iterate quickly. The way to achieve great software is also to iterate quickly. That is not a coincidence. Willingness to withstand a little bit of breakage allows companies to move fast. This contributes to an overall _higher_ level of quality, leading not to frequent outages (Facebook does not have frequent outages and failure), but to more robust product.
I am aware of how people build software in more traditional fields (my background is in compilers and static analysis). I am also aware that traditional software development techniques are being eclipsed by those who are willing to throw off the shackles of the past. The "hackday coding methodology" may not be useful to make the code for your car, but the techniques used to build your car are not useful for building a successful SaaS product.
