To OP's point, at what point do we consider the Chesterton's fence effect? Pointing out code quality problems is of course easy when the effects of those quality problems are obvious, but as OP mentioned, Facebook is working at a scale that isn't likely familiar to most critics. Sometimes, when things get big enough, you have to do things that nobody else is doing, because nobody else has the problems that you have.
If all you've ever built was houses, it's hard to give too much credence to your critique of a skyscraper, especially if you aren't privy to the underlying geographical features like bedrock depth, wind velocity at altitude, etc.
> If all you've ever built was houses, it's hard to give too much credence to your critique of a skyscraper, especially if you aren't privy to the underlying geographical features like bedrock depth, wind velocity at altitude, etc.
This analogy isn't apt. We're talking iOS app development versus Facebook's iOS app development. This is a very easy to compare thing. Yes, with Facebook's scale they likely run into some interesting issues than many will never but that doesn't make it into something vastly different. It's still an iOS app that may have more optimizations than other apps.
It's like comparing a regular house being built and a house that has to support every type of person in existence. They're still a house.
I find the skyscraper comparison actually quite apt. You build an app that is 10 features, while the main facebook app itself is 100s of features. When you build a building that is more than 20 stories high, you have to change everything about that building. No more wood construction, you have to use steel, you have to think about the bedrock, you need to put in elevators and so on.
I bet if facebook was able to ship an app that only came with the mostly used %20 and was able to download the 100kb of binary for each of the mini features inside their app on demand, it would be a far more scalable application. But they cant, because iOS stops them.
Not a skyscraper, then; rather, a house, but one which had to be built of brick-sized prefab components, where a constant revolving door of contractors and architects worked either by adding or replacing bricks one-at-a-time.
To put that another way: sometimes the problem isn't the problem. Sometimes the ungainliness of the tool or process used to solve the problem, is the problem. If you've got a 1000-ton hammer, you might (in theory) be able to hammer a nail, but you've got some other logistical challenges to solve first.
Chesterton's fence is a good reason to lament rather than forgive the ugliness in a large existing code-base. That's because it makes it hard to distinguish what is genuinely necessary from the genuinely bad ideas.
My experience with huge real-world code bases is that yes they do encode lots of important functinal knowledge about real-world requirements that a new programmer will not see. But it will also contain even more plain old stupidity.
If all you've ever built was houses, it's hard to give too much credence to your critique of a skyscraper, especially if you aren't privy to the underlying geographical features like bedrock depth, wind velocity at altitude, etc.