Why is the LinkedIn app almost half a gig?

[1] https://en.wikipedia.org/wiki/Dangling_modifier

[2] https://en.wikipedia.org/wiki/Garden-path_sentence

> 1) where are the architects? Arent they supposed to deal with such issues?

The architects are the ones being told “we need these features, figure out how to do it”, and they build little box charts and sequence diagrams to sort out which systems are responsible for which. Never mind if a “feature” could just be a few functions somewhere. Architects think in terms of boxes and what does what. If the current boxes don’t have a role for a new feature, a new box is created. Boxes are assigned to engineers and interfaces are designed. Nobody cares if things can be done more simply, because the architects are looking to climb the ladder too (more boxes means your job is more justified.)

These same architects often don’t understand what each box actually does in implementation either, so they often are blind to radically simpler approaches to problems (I’ve seen cases where people just have no idea that a box already does the thing they want to do, and instead spend an entire quarter trying to build the functionality into the edges of the system, plumbing huge amounts of stuff around, when the thing they wanted could have been a 2-line change. These are fun meetings when that realization happens.)

> 2) nobody measures such metrics: size, bloat, speed...

They might be measuring speed, but with a kind of perverted reverse ratchet, where they say “this is within X% of production, so the regression is acceptable” and it ships. Once a perf regression ships it becomes the new baseline, so the next change can then be within X% of this one, and in turn the product gets exponentially slower. Nobody ever looks more than one release back. Nobody ever sets out to improve speed, unless by happy accident. If you stumble upon some horribly slow thing and fix it in happenstance, you can get a nice bonus. It’s never the plan though.

> 3) where are the code reviews?

There are code reviews but they’re completely toothless because the person making the change can easily say “this is high priority for making $DEADLINE” and push it through while filing a ticket to fix it properly in a follow up. The follow up never happens, and in turn any bad code becomes the new baseline and used as an excuse to make the same bad choice in other areas.

If you actually reject a PR and push back against the deadline, you are considered not a team player, and, guess what? You will get routed around anyway. They will find a way to get this change into another part of the system you don’t control (because code owner’s files mean there’s probably some other place they can make the change at some cost to the system complexity. This is another factor in (1), because the code base has fiefdoms and often architectural boxes are created purely because nobody wants to make PR’s into box A because of that one grumpy engineer, so functionality is built into box B instead.)

> 4) nobody checks if the same library, same icon pack are not attached twice?

Yes but there’s always an excuse, see 3.

> 5) 1000 people? What do they even do? I suspect a lot of slides, politics and "high visibility projects"

The bureaucracy expands to meet the needs of the expanding bureaucracy. All this complexity needs tooling, all this tooling causes complexity. Existing behavior is used to justify bad decisions, bad decisions become existing behavior, the cycle repeats.

The real problem with these organizations is that nobody dare admit (or even attempt to understand) how few engineers these kinds of products could require if things were done carefully from the start. And after years of such an org, shrinking becomes impossible: the weight of the complexity of the product means you need all the engineers you have to manage it. The mistakes were already made and there’s no way to close Pandora’s box here. You have to carry on until some day it just collapses (or gets disrupted, etc.)

> Not related to Libkedin, but what is the carbon footprint of all electron-based apps that take hundreds of megabytes and gigantic amount of processor time?

Trust me I’d love to hate on electron and JavaScript as much as the next person, but all you read above is from an org where we write bare metal code using as many system frameworks as possible, using everything we can that’s native to the platform. No JS, no GC’d languages, no electron/etc. As native of an app as you can get. This stuff has basically nothing to do with tech stack, it’s all organizational. I’ve heard it described as “building software at large” but it really means “letting the software grow unchecked”, and it’s the attitude that’s the problem, not the technology.