Let's avoid putting here obvious companies and companies who over-engineer, maybe?
http://quellish.tumblr.com/post/126712999812/how-on-earth-th...
https://www.reddit.com/r/programming/comments/3m5n2n/faceboo...
As for the 18k classes in their iOS app, I don't see why this is a sign of bad engineering? I'd expect that a large number of these are auto-generated, for example from Thrift API definitions, and I'd also expect that what we see as users is the tip of the iceberg in terms of the code needed. There's obviously a lot of analytics code, and also I'd expect the resiliency and reliability needed requires much more code than we'd expect.
Scale is handled at the back-end.
As a small-company person who migrated a few years ago to one of the Big Four, I can confirm that almost every time someone tells you about "scale" they are bullshitting you. Most developers on those companies either do not deal with scale at all (anyone dealing with front end stuff) or do so by using abstractions which allow them to ignore scale (99% of developers). But scale sounds sexy so everybody pretends they have something to do with it. And it sounds better than "bloat" which is what they really mean.
The other variant of "scale" is "I have this single-computer application running on X hundred thousand servers" or some ambarrasingly parallel problem of that sort. Then they will claim boldly that something that has a 0,0001% chance of happening "happens multiple times a day here" which sounds impressive until you realize that that thing has no impact on the SLA and you get saved by the load balancer so it isn't particularly important anyway.
The 1% of people who work on real problems in the area don't need to brag on the Internet about "scale" because they are too busy working.
The light FB app probably does very well by class count metrics, but it's intended for a totally different market. Stateside, much as we may bitch about it, it apparently doesn't matter for an app in FB's position.
Facebook wants the shortest possible time between product idea and real world users interacting with it, which is why they also have a solid CI/CD pipeline. You might not agree with the tradeoff, but the pragmatism is impressive
What makes you believe this is "clever" as opposed to a poor engineering decision? I strongly suspect that FB might have delivered a higher quality product through a more traditional team-ownership development model. Throwing large numbers of developers at a single app is unlikely to lead to a well-architected holistic solution.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...