- The Facebook app is huge in terms of features. Just look at the menu with more things. I use very few of them, yet they're all pretty popular and justify themselves.
- Instagram is smaller than Facebook, but still has a lot in it.
- A lot of our code was optimized over time in many ways that add a lot of edge cases: internationalization, accessibility, optimizations for dealing with media, loading and data. It's can be easy to write something with much less code that looks pretty good at first sight, but all those extras really make the experience better and pay off for users.
- We build new features all the time, some code may be unreleased, some is in A/B testing and so you can have two or more pieces of code that do the same.
- A lot of test code.
- Not that much dead code. Trust me. I love deleting code! And I will happily spend time removing bloat. There's definitely a lot of dead code to remove, but it won't change those top line numbers by much.
(Also, it's 10M Kotlin lines of code, we have much more)
(I would love to know how many lines of code the other really big companies with big mobile apps have for comparison)
> Today, our Android apps for Facebook, Messenger, and Instagram each have more than 1 million lines of Kotlin code, and the rate of conversion is increasing. In total, our Android codebase has more than 10 millions lines of Kotlin code.
Probably 1000 engineers working on an app with each writing 1000 lines of code. I am not surprised Facebook app has >1 million lines of code. The app is bloated with features that it's user unfriendly.
I have parents that are pretty not tech literate (they didn't how to save contact or send SMS) but they have no trouble navigating Facebook app for the core set of features they use.
I would like to know your arguments against it. How would you define a maximum count of LOC, why would you set that particular limit, and how would you address the "problem" if your team were to hit that limit?
