(At IMVU our VP of Operations is also our VP of Engineering)
The basics are:
understand each other
automate automate automate every little thing
automate automate automate every big thing
profile the results
Social networks are about the opposite, as a lot of the content isn't really "yours", it's a result of interaction. I made no reference to this in my comment though, so thanks for pointing it out :)
From the outside it sounds like it would be a nightmare to manage. How could you sanely test all the permutations of "Feature X on, Feature Y off, Feature Z = 4"?
You don't need to test every permutation. Pretty much all of the flags in the codebase are independent of each other - someone might be working on changes to our admin interface in some files while someone else is changing the way comments are displayed elsewhere. There's no overlap in the changes.
If the flags do interact with each other then in most cases the features will launch one after another, so you only need to test a handful of states (foo off bar off, foo on bar off, foo on bar on)
If the flags interact with each other and the features will be launching at the same time (or the betas overlap) then you have to do the same amount of integration testing that you'd have to do with landing several branches into trunk at once. This is complex, we don't do it very often.
And we clean up flags once they're not needed any more, which minimizes the possible combinations.
I was skeptical about this before I started working at flickr, now I can't imagine working any other way.
We're looking at what we can do to adopt continuous deployment in our own shop. I suspect that it requires a bit of rethinking how development happens.
You get even more out of config flags when deploying non-user facing changes - nobody knows if you roll it back so you can turn it off and on as many times as you need to get detailed data on exactly what impact the new code has on your metrics (both business and infrastructure).
One thing we don't use flags for is changes in the layers below the application - the OS, web server, php libraries etc. It's much easier to roll these out server by server.
The video of the presentation, which might give more context, is here: http://velocityconference.blip.tv/file/2284377/
(please pardon my potty mouth on the video)
last one I recall was the flashy album manager and video, both wich i rarely uses.