The loop of app building:
1. Build app with native framework.
2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms.
3. Re-build app with native framework, because it is faster.
4. GOTO 2
The best part about this cycle is that developers can always point to some metric which shows improvement to justify their actions, resulting in an Escher-like loop where they think they’re always going up.
These cycles pop up all the time in development as priorities shift (or as developers find more excuses to “fix” what isn’t broken). Real world coding always involves compromise - leadership is recognizing which compromises to make without continually backpedaling.
To be fair, small fast messenger 2020 is "better" (aka more features / millisecond of cold start) than small fast messenger 2016. The cycle doesn't always go up monotonically, even if developers pretend it does. But it is possible to go "full-circle" through the loop and wind up in a better place than you started, and it's even possible for each stage of the loop to be truly justified given product needs.
indeed, it could be rational business needs. at a time when it's more expensive to hire devs, maybe it looks better to have a single codebase. at a time when performance is more valued, maybe it's better to rewrite in native.
I don't know what world you live in, but in my world developers don't have to look for excuses to do work. Perhaps some companies running on endless VC overhire, but the real working world has fewer employees for most positions than it needs.
And in the case of Messenger, I highly doubt it was the developers who said, "Hey, let's add this completely unrelated thing to our codebase - payments!". More likely it was marketing or "product" that told the devs what to add.
From TFA: "We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000."
Sounds like not only did they make the app quicker and lighter, they improved code maintenance too. If the android app is as the same size as the new ios messenger app, they'd still have less code to maintain than the previous ios messenger app.
How in the name of everything did they manage to write 1.7M lines of code for a messenger app? That is an astonishingly large code base! We're talking about an instant messenger app with heaps of features, having a LoC footprint 3.5% of the size of modern Windows.
> Since then, we’ve added payments, camera effects, Stories, GIFs, and even video chat capabilities
Simple: they added tons of crap nobody care. On this list, I only use video. Messenger is valuable because of the network effect, but feature wise 2003’s MSN was good enough.
That's not true, the application, whether you like or not, it full of micro-interactions, well-done animations and transitions, features like the payment or stories, you can take photos directly from the app, etc.
With that many features, it doesn't surprise me that the previous codebase was 1.7M LoC. Sure if you count only the messaging part, I'm fairly certain that the LoC is way lower than this.
It doesn't make sense to compare the number of LoC of messenger to the number of LoC of software like Postgres because Postgres tries to be good at 1 thing and messenger tries to have a ton of features with good UI and UX.
I don't like many of their features (I'm not using the stories or the payment), but some of my friends do and you have to recognize the work that the messenger team did to make them work that well.
One of their points in the article was how they've decided to use more of the native OS interfaces instead of implementing their own versions (!!). For instance, using the OS's native threading library instead of writing their own. So, the number of LoC kinda start to make sense when you think about them re-implementing some not-trivial chunk of an OS's native functionality.
I've never felt the need to justify my own existence. There's always been a longer backlog of work than my teams would ever get through and managers who appreciated the work getting done.
Another plausible explanation is lack of code re-use and reinventing the wheel because you don't know someone else solved the same problem. Also correlates with number of engineers.
I had the same question... And that's not counting LOC on the server. And all of this is for... glorified text messaging, right? I don't use FB so I could be missing context or features.
I wonder how this will effect Lite. I use it over Messenger strictly to reduce bloat and get an app with the bare essentials of chat and calls fol friends that refuse to use Signal.
the reason is they're high paid engineers without skin in the game. Fb is already making money, hence a lot of engineering efforts are not related to having fb make money, but to prove the engineer's worth.
Somehow younger generations are allergic to it, you seldom see it listed as alternative for portable busines code, even though it is available out of the box in all mobile SDKs, with first class IDE support alongside the respective upper layer languages on the platforms.
And the amount of time spend writing a bit of glue code, specially on Android, is still less than debugging integration issues in all those Hybrid/Abstration frameworks.
