Last Friday I had the chance to take part to Mobile@Scale conference at Facebook HQ in Menlo Park.
The underlying question of the conference was “how do the web Giants (Facebook, Linkedin and Twitter) handle the scale of the mobile product as far as both the users and the dev team are growing”.
It was targeting developers and CTOs.
Here is a few interesting facts brought up for the main ideas discussed and what we can take out of it:
Metrics and Analytics and A/B testing
Everyone put a lot of emphasis on how important metrics and mobile analytics are and how long it took them to realize it.
e.g: Linkedin realized that the time to switch from one screen to another was very slow in their early version.So they decided to revamped their app with the transition time as one of top priority.
(Fun fact: for every request to the server they measure the response time and send it to the server in the header of the next request).
e.g: Facebook discovered that with their new hamburger menu, the “likes” and “comments” dropped significantly (the new elements of the newsfeed were not shown to the users as often, since the newsfeed was not the “root” screen of the app anymore). They A/B test a lot of different designs to bring this number back to the origninal state (the solution is to display red badges near the “Newsfeed” option everywhere in the application).
Even if you don’t have 800M users (like Facebook!), knowing your users is key. And you don’t have to create your own analytics framework, Flurry or Mixpanel do it very well for you.
Git and Source control systems
Git is used by everyone talking there. Facebook uses Phabricator
as code review system and chants the praises of it. Twitter uses Gerrit
Facebook, Twitter and Linkedin switched from a “branch” release management style to “release train”
management style with feature switches: everyone works on the trunk, the new features enabled with a flag, the release is scheduled to go on a D date, the features ready for the release date are enabled, the others stay disabled.
Twitter, went further in making those feature flags toggleable server side. So new features can be shipped with the client and remain muted until the API is ready server side.
Facebook and twitter have (very) big mobile developer team (+100 “mobile committers” at Facebook, twitter increase the “mobile committers” by 10 over the last months) so they had to come up with solid code review process and managing and merging dozens of branches at the time is impossible.
As a small dev team it’s ok to keep your scrappy code review routine (e.g: use feature-based branches and send pull requests to other developers of the team, when we are done with a feature).
The feature flags idea is an interesting idea to keep in mind, and is not necessarily restricted to the source control context.
Beta program and Testing
Facebook, Twitter and Dropbox use the new Google Play Beta program
and are really happy with it (Facebook even have a separate alpha program sending 1 update a day via Google Play).
Dropbox uses it to test the latest changes of “libdropbox” (their C++ lib shared accross iOS and Android).
All those companies have a really intensive use of tests (Unit test, integration test, UI tests using snapshots, “blackbox” manual testing, etc…).
Depending the size of your user base and the commitment of your community, it is really something you should use if you can.