4 ms·
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 ra
by 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 agoThe 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.