7 ms·

I think Facebook has very poor engineering culture. They built their iOS app with 18k classes, then claim that iOS and Git can't handle their 'scale'. Let's av

by akerro 10y ago

I think Facebook has very poor engineering culture. They built their iOS app with 18k classes, then claim that iOS and Git can't handle their 'scale'. Let's avoid putting here obvious companies and companies who over-engineer, maybe? http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so http://quellish.tumblr.com/post/126712999812/how-on-earth-th... https://www.reddit.com/r/programming/comments/3m5n2n/facebook_engineer_ios_cant_handle_our_scale/ https://www.reddit.com/r/programming/comments/3m5n2n/faceboo...

treehau5 10y ago
The first tumblr link at the bottom in the comments linked me to FizzBuzz Enterprise Edition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
danpalmer 10y ago
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.
- mattmanser 10y ago
  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.
  - throwaway698769 10y ago
    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.
  - Bahamut 10y ago
    That's not quite true - frontend has to scale for features.
  - mercer 10y ago
    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)?
    - nailer 10y ago
      Unreal Engine.
      - Psilidae 10y ago
        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.
- mi100hael 10y ago
  Auto-generated code shouldn't be checked in.
  - danpalmer 10y ago
    I believe the 15k number came from decompiling the binary, not from looking at source control.
billjings 10y ago
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.
010a 10y ago
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.
thecupisblue 10y ago
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.
- V-2 10y ago
  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-105776.html https://jaxenter.com/facebooks-completely-insane-dalvik-hack...
JoeCortopassi 10y ago
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
- mcguire 10y ago
  The architecture of all software projects eventually matches the structure of the organization writing the software.
- p-squared 10y ago
  > 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.

by akerro 10y ago

treehau5 10y ago

The first tumblr link at the bottom in the comments linked me to FizzBuzz Enterprise Edition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

danpalmer 10y ago

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.

mattmanser 10y ago
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.
- throwaway698769 10y ago
  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.
- Bahamut 10y ago
  That's not quite true - frontend has to scale for features.
- mercer 10y ago
  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)?
  - nailer 10y ago
    Unreal Engine.
    - Psilidae 10y ago
      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.
mi100hael 10y ago
Auto-generated code shouldn't be checked in.
- danpalmer 10y ago
  I believe the 15k number came from decompiling the binary, not from looking at source control.

billjings 10y ago

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.

010a 10y ago

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.

thecupisblue 10y ago

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.

V-2 10y ago
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-105776.html https://jaxenter.com/facebooks-completely-insane-dalvik-hack...

JoeCortopassi 10y ago

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

mcguire 10y ago
The architecture of all software projects eventually matches the structure of the organization writing the software.
p-squared 10y ago
> 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.