3 ms·

Can anyone shed light on where the complexity is coming from? Even 360kloc for a chat client seems excessive - its original size, 1.7Mloc, is hard to accept. Ho

Can anyone shed light on where the complexity is coming from? Even 360kloc for a chat client seems excessive - its original size, 1.7Mloc, is hard to accept. How does it break down - e.g. 120kloc UI, 120kloc networking/data, and 120kloc other? (For comparison I dl'd https://github.com/signalapp/Signal-iOS https://github.com/signalapp/Signal-iOS and ran cloc. It's about 400kloc of Swift, so I guess it's in the ballpark. I just wouldn't have guessed it was so big, and I'd like to know why.)

SOLAR_FIELDS 3y ago
Just conjecture here since I have not ever done work in the messenger space: Perhaps it’s like Uber in that all of the complexity comes from localization features? Edit: I saw another post further down that hypothesized that all of the complexity was with integrations outside of barebones messaging like photos, calls, other Facebook products etc. which seems plausible as well
j45 3y ago
One guess: abstracting abstraction enough times can accomplish pretty much any Mloc.
lanza 3y ago
Because you don't make money deleting code. People at tech giants don't love their employers like they are their mother or something. They don't do things that don't get them rewarded. Implementing new features does. And so engineers implement new features and write more code and release the features and get rewarded for doing so. Once the feature is done, if it's easy to delete it they will. If not, and it never is, they'll leave it around and move on to something else. When you have 3 billion users if you make the company 1/100th of a penny per user per year you pay for yourself. That's like increasing the value of the average user by 1/200,000. So your feature doesn't even have to be that good. It just has to be minimally better than what it's replacing. Restyle a button to be more appealing in the peripheral vision of users and that probably breaches that threshold. Reality is that it isn't quite this easy (fewer users are that valuable, most don't use it daily, etc). But it gets the point across. You work there to make more money and deleting some feature that is probably referenced by some other dead code somewhere else isn't profitable work for anybody.
- wpietri 3y ago
  Well that's a grim tragedy of the commons. Not that I doubt you at all, but how depressing!
  - lanza 3y ago
    Why is it depressing? Does some collection of people on earth suffer from tech giant apps having too many lines of code? It very effectively shovels money from these soulless companies into the pockets of the employees. No living entity is suffering, just the company from it's own bloat. I find it to be quite a beautiful result. Developers get to develop and not focus on maintenance. The lack of local maintenance creates repository wide maintenance jobs that are also interesting in their own right. It is tragedy of the commons. But really the only one who deals with the tragedy is the corporate entity.
    - wpietri 3y ago
      Companies don't suffer. That is reserved for the living. The depressing part is the large amount of waste here. Wasted time, wasted opportunity, wasted money. Wasted lives. What you're doing here is known as the broken window fallacy. The same developers could be developing meaningful things. They could be learning, like adults do, how to clean up after themselves, and so lead richer lives. The people forced into being code janitors could spend their time making things that actually get used. Or everybody could just do less work and go home early, doing things they care about. And speaking of use, let's note that the waste impacts the users and the world. The users could be getting better software. More useful features. Fewer bugs. New products, new ideas. They could also avoid a lot of the chaos that comes when a company dies of pernicious waste. For example, note that the original browser company, Netscape, failed due to poor code maintenance, letting IE take over. What might have happened if they had done better?
- userbinator 3y ago
  I don't think it's the feature count that's in question; it's the ratio of feature count to lines of code that seems abnormal.
userbinator 3y ago
My bet is on "object-oriented obfuscation" and bloat caused by "modern" coding styles. Looking through the Signal source you linked to, I see tons of the former. There is an absolutely insane amount of boilerplate-looking code in here, for example: https://github.com/signalapp/Signal-iOS/tree/main/Signal/src/ViewControllers https://github.com/signalapp/Signal-iOS/tree/main/Signal/src... I don't know Swift or the iOS UI API, but a lot of that code seems to be manually creating and positioning UI elements and otherwise implementing UI functionality that I'd expect the OS to handle. It's a lot of code that should really be data (arrays, structures). To offer a huge contrast, a long time ago I wrote an MSNP chat client in pure Win32, and it was around 2kloc. The binary was 24KB. Of course it only supported contacts, presence, and text messaging, but I still can't see features like audio/video or the crypto that Signal has needing 100x more, especially if they use OS functionality for much of them.

SOLAR_FIELDS 3y ago

Just conjecture here since I have not ever done work in the messenger space: Perhaps it’s like Uber in that all of the complexity comes from localization features? Edit: I saw another post further down that hypothesized that all of the complexity was with integrations outside of barebones messaging like photos, calls, other Facebook products etc. which seems plausible as well

j45 3y ago

One guess: abstracting abstraction enough times can accomplish pretty much any Mloc.

lanza 3y ago

Because you don't make money deleting code. People at tech giants don't love their employers like they are their mother or something. They don't do things that don't get them rewarded. Implementing new features does. And so engineers implement new features and write more code and release the features and get rewarded for doing so. Once the feature is done, if it's easy to delete it they will. If not, and it never is, they'll leave it around and move on to something else. When you have 3 billion users if you make the company 1/100th of a penny per user per year you pay for yourself. That's like increasing the value of the average user by 1/200,000. So your feature doesn't even have to be that good. It just has to be minimally better than what it's replacing. Restyle a button to be more appealing in the peripheral vision of users and that probably breaches that threshold. Reality is that it isn't quite this easy (fewer users are that valuable, most don't use it daily, etc). But it gets the point across. You work there to make more money and deleting some feature that is probably referenced by some other dead code somewhere else isn't profitable work for anybody.

wpietri 3y ago
Well that's a grim tragedy of the commons. Not that I doubt you at all, but how depressing!
- lanza 3y ago
  Why is it depressing? Does some collection of people on earth suffer from tech giant apps having too many lines of code? It very effectively shovels money from these soulless companies into the pockets of the employees. No living entity is suffering, just the company from it's own bloat. I find it to be quite a beautiful result. Developers get to develop and not focus on maintenance. The lack of local maintenance creates repository wide maintenance jobs that are also interesting in their own right. It is tragedy of the commons. But really the only one who deals with the tragedy is the corporate entity.
  - wpietri 3y ago
    Companies don't suffer. That is reserved for the living. The depressing part is the large amount of waste here. Wasted time, wasted opportunity, wasted money. Wasted lives. What you're doing here is known as the broken window fallacy. The same developers could be developing meaningful things. They could be learning, like adults do, how to clean up after themselves, and so lead richer lives. The people forced into being code janitors could spend their time making things that actually get used. Or everybody could just do less work and go home early, doing things they care about. And speaking of use, let's note that the waste impacts the users and the world. The users could be getting better software. More useful features. Fewer bugs. New products, new ideas. They could also avoid a lot of the chaos that comes when a company dies of pernicious waste. For example, note that the original browser company, Netscape, failed due to poor code maintenance, letting IE take over. What might have happened if they had done better?
userbinator 3y ago
I don't think it's the feature count that's in question; it's the ratio of feature count to lines of code that seems abnormal.

userbinator 3y ago

My bet is on "object-oriented obfuscation" and bloat caused by "modern" coding styles. Looking through the Signal source you linked to, I see tons of the former. There is an absolutely insane amount of boilerplate-looking code in here, for example: https://github.com/signalapp/Signal-iOS/tree/main/Signal/src/ViewControllers https://github.com/signalapp/Signal-iOS/tree/main/Signal/src... I don't know Swift or the iOS UI API, but a lot of that code seems to be manually creating and positioning UI elements and otherwise implementing UI functionality that I'd expect the OS to handle. It's a lot of code that should really be data (arrays, structures). To offer a huge contrast, a long time ago I wrote an MSNP chat client in pure Win32, and it was around 2kloc. The binary was 24KB. Of course it only supported contacts, presence, and text messaging, but I still can't see features like audio/video or the crypto that Signal has needing 100x more, especially if they use OS functionality for much of them.