Even worse, look at their Android app - They made an overly complex open source image loading library which is despised by most quality Android Engineers because it uses parts of memory it shouldn't be using, switching to and from it is terrible, has a big dex footprint and often results in OOM crashes. They use runtime hacks and then complain directly to Android developers when something breaks during updates, their SDK is terrible and pulls a ton of dependencies, they made a "2D physics engine" just to make a bounce animation. Met a dozen of their developers and I have noticed way more arrogance than brilliance. None of them are the kind of people I'd like to work with.

The most mind-boggling thing they did with their Android app (that I know of, at least) was hands down this: https://jaxenter.com/facebooks-completely-insane-dalvik-hack...

I've spoken to Facebook engineers who work on their internal source control systems, and it was pretty obvious from talking to them that Git wouldn't work for their purposes. There is plenty of writing about this topic that explains in some detail why Git is unsuitable, and why Mercurial was a better option for them.

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.

Auto-generated code shouldn't be checked in.

I believe the 15k number came from decompiling the binary, not from looking at source control.

It's nothing more complex than 100,000s of other apps out there. Yet somehow they managed to create 18k classes?

Scale is handled at the back-end.

You are completely right.

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.

I can't immediately think of any apps that are just as complex as Facebook's, but maybe I'm just not thinking hard enough. Could you give me some examples (honest question)?

Unreal Engine.

Based on their documentation—which, albeit, I know has many classes omitted—Unreal Engine has ~6900 classes. That number probably gets greatly multiplied, though, if you count generated classes.

And it's managed in git.

I can't find the link, but I remember an Epic engineer saying that they use Perforce internally and do a 2 way sync with Github.

Correct, it is managed in Perforce and MIRRORED onto Github.

I'd think that the Google+, Google Photos, the Twitter apps are at at least 75% of the complexity of the Facebook app.

That's not quite true - frontend has to scale for features.

But does the app make money? Do people use it?

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.

The problem of 'scale' they were addressing in the iOS app wasn't scale of users, but rather scale of devs. They have 18k classes because they came up with a rather clever way of allowing many separate developers to all work on different features of the same app, without stepping on each others toes. This might not seem like a hard problem if you've never worked on a non-trivial iOS app, but it is a pretty impressive feat.

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

The architecture of all software projects eventually matches the structure of the organization writing the software.

> They have 18k classes because they came up with a rather clever way of allowing many separate developers to all work on different features of the same app, without stepping on each others toes.

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.

The first tumblr link at the bottom in the comments linked me to FizzBuzz Enterprise Edition

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I'll be very blunt: In situations like this, they are far far closer to the code than an armchair observer like you. I trust their engineers far more than I respect your pithy complaints.