4 ms·

1) where are the architects? Arent they supposed to deal with such issues? 2) nobody measures such metrics: size, bloat, speed... 3) where are the code review

by rvba 3y ago

1) where are the architects? Arent they supposed to deal with such issues? 2) nobody measures such metrics: size, bloat, speed... 3) where are the code reviews? 4) nobody checks if the same library, same icon pack are not attached twice? 5) 1000 people? What do they even do? I suspect a lot of slides, politics and "high visibility projects" Meanwhile the product suffers. Companies sure talk a lot about ecology, then we get apps like that. 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?

ninkendo 3y ago
Speaking from experience in a similarly unhealthily large org: > 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.
- LAC-Tech 3y ago
  This was incredibly well written and I really enjoyed it. Never worked for a large org but if I extrapolate stuff I've seen in smaller places I can see how this would be the end result.
  - fuzzfactor 3y ago
    >if I extrapolate stuff I've seen in smaller places Makes me wonder where they got their ideas, maybe they are just imitating larger companies. It's real bad when you get a refugee from a large bureaucratic org into any key position somewhere much smaller that would really need to grow a lot to compare at all. Ultimate decision-makers sometimes think that type of overpaid climber will prepare them to grow to the size of the company they once worked at. When the opposite is true because they thrive on the bureaucracy more than the business, and can barely perform when all that overgrown bureaucracy is not there at their disposal. And you don't want to pattern your company like a large bureaucracy until it is actually large. And then only deploy the bureaucracy part judiciously when and if it becomes absolutely necessary, no reason to do it the 19th century way any more. From another comment: >Sounds like bad product management as much as bad engineering. I mean, the outcome — a bloated product — is bad for everyone: the users in the first place, the engineers building the product, but also the PM who can't conceivably be proud of shipping a bad product. "Bless their hearts, they don't know any better." "This is why we can't have good things."
bcaxis 3y ago
> nobody measures such metrics: size, bloat, speed... Have you ever looked at the bloat of linkedin web? I've had tabs over 1GB memory use. Most bloated site I've ever used with any kind of regularity. > 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? I make an election app. It uses 70-80 mb of RAM when running. It's not that bad when you don't blow out your dependencies and code structure.
- rvba 3y ago
  I actually was looking recently at memory (and processor) usage of my browsers. I often have multiple tabs open since I revisit some sites. Biggest culprits of memory bloat seem to be discord, linkedin and a specialist page that shows some maps. Gmail (!) feels incredibly bloated now as well - it has random jumps in processor usage, especially when loading. At the same time: firefox simply is uncompatibile with youtube - random freezes and lags. There are multiple therds about it on the intetnet. Some say that youtube is intentionally slowing down firefox. I think nobody at firefox uses own browser so they dont know youtube runs bad with an ad blocker. Also probable reason is that they try to kill firefox by conforming to some web standard (just like conforming to .webm - when you save pictures from reddit they arent saved as .png, but as the crappy .webm - I guess someone at mozilla is working very hard to lose the last few users they have. And yes I am aware you can solve this with an addon. An addon that is not checked for viruses / spyware)
  - scriptkiddy 3y ago
    My experience with FireFox and YouTube has very much not been this. YouTube works perfectly for me on FireFox. I would check your config/addons and see if there is some setting that is causing errors on YouTube.
Ringz 3y ago
> 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? Whether the CO2 footprint is high or low (and I assume it is very high), the real problem is that it would be a very simple way to improve CO2 efficiency.

by rvba 3y ago

ninkendo 3y ago

Speaking from experience in a similarly unhealthily large org: > 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.

LAC-Tech 3y ago
This was incredibly well written and I really enjoyed it. Never worked for a large org but if I extrapolate stuff I've seen in smaller places I can see how this would be the end result.
- fuzzfactor 3y ago
  >if I extrapolate stuff I've seen in smaller places Makes me wonder where they got their ideas, maybe they are just imitating larger companies. It's real bad when you get a refugee from a large bureaucratic org into any key position somewhere much smaller that would really need to grow a lot to compare at all. Ultimate decision-makers sometimes think that type of overpaid climber will prepare them to grow to the size of the company they once worked at. When the opposite is true because they thrive on the bureaucracy more than the business, and can barely perform when all that overgrown bureaucracy is not there at their disposal. And you don't want to pattern your company like a large bureaucracy until it is actually large. And then only deploy the bureaucracy part judiciously when and if it becomes absolutely necessary, no reason to do it the 19th century way any more. From another comment: >Sounds like bad product management as much as bad engineering. I mean, the outcome — a bloated product — is bad for everyone: the users in the first place, the engineers building the product, but also the PM who can't conceivably be proud of shipping a bad product. "Bless their hearts, they don't know any better." "This is why we can't have good things."

bcaxis 3y ago

> nobody measures such metrics: size, bloat, speed... Have you ever looked at the bloat of linkedin web? I've had tabs over 1GB memory use. Most bloated site I've ever used with any kind of regularity. > 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? I make an election app. It uses 70-80 mb of RAM when running. It's not that bad when you don't blow out your dependencies and code structure.

rvba 3y ago
I actually was looking recently at memory (and processor) usage of my browsers. I often have multiple tabs open since I revisit some sites. Biggest culprits of memory bloat seem to be discord, linkedin and a specialist page that shows some maps. Gmail (!) feels incredibly bloated now as well - it has random jumps in processor usage, especially when loading. At the same time: firefox simply is uncompatibile with youtube - random freezes and lags. There are multiple therds about it on the intetnet. Some say that youtube is intentionally slowing down firefox. I think nobody at firefox uses own browser so they dont know youtube runs bad with an ad blocker. Also probable reason is that they try to kill firefox by conforming to some web standard (just like conforming to .webm - when you save pictures from reddit they arent saved as .png, but as the crappy .webm - I guess someone at mozilla is working very hard to lose the last few users they have. And yes I am aware you can solve this with an addon. An addon that is not checked for viruses / spyware)
- scriptkiddy 3y ago
  My experience with FireFox and YouTube has very much not been this. YouTube works perfectly for me on FireFox. I would check your config/addons and see if there is some setting that is causing errors on YouTube.

Ringz 3y ago

> 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? Whether the CO2 footprint is high or low (and I assume it is very high), the real problem is that it would be a very simple way to improve CO2 efficiency.