6 ms·

Optimize the Overall System Not the Individual Components

40 points by max_ 2y ago

smitty1e 2y ago
> And the organization suffers even while improving results of components One properly and three half-flat tires on a car is an obvious visual here. The counter-argument is that one must begin somewhere; waiting until everything is "chef's kiss" might mean much waiting.
andsoitis 2y ago
Related concept: you usually make a tradeoff when designing for a resource constraint. Once the resource constraint is removed, you’re still paying the cost but no longer get the benefit of the tradeoff.
apantel 2y ago
I just want to make a comment about optimizing applications even though the article is about optimizing organizations: The way to arrive at the optimal system is to continually optimize all individual components as the system develops. You have to walk the razor’s edge between “premature optimization is the root of all evil” and not optimizing anything until it’s too late and a bunch of bad design decisions have been baked in. If you want to write the fastest program, profile its performance from the start and try different ways of doing things at each step of the process. There’s usually a way of doing things that maximizes simplicity and performance at the same time because maximum performance == doing as little work as possible to complete a task. Chances are that ‘littlest amount of work’ will be elegant.
- llamaimperative 2y ago
  Ehhh this isn’t quite the right takeaway, or at least it’s contrary to Deming’s approach. The key insight from Deming’s work is that at any given moment there is only and exactly ONE thing that should be optimized. Once you optimize that, there will be a new SINGLE thing that is now slowing down the entire system, and must be optimized. The goal of an engineer of a system (or manager of an org) is to develop a method to repeatedly identify and improve each new bottleneck as it appears, and to ignore other components even if they’re apparently not performing as well as they could.
  - Jensson 2y ago
    That is what everyone currently and we know the results, that only takes you from horribly slow to very slow. In order to have a chance to get anywhere close to fast you need each component to already be very fast, and then you can build a fast system on top of those. When you work with slow components you wont use the right architecture for the system, instead you start working around the slowness of each component and you end up with a very slow mess. Example: A function call is slow, it calls a thousand different things so you speed this up by putting a cache in front, great! But now this cache slows down the system, instead you could have sped up the function calls execution time by optimizing/trimming down those thousand things it calls. Adding that cache there made you get further away from a fast system than you were before, not closer. One cache is negligible, but imagine every function creating a new cache, that would be very slow and basically impossible to fix without rewriting the whole thing.
    - rudasn 2y ago
      OK so the cache is the one thing, and the next most expensive "little thing" is the one thing to focus on next?
      - Jensson 2y ago
        But removing the cache makes the system slower, it didn't optimize anything. So no, fixing this isn't possible with that approach, you need to take the holistic approach.
        llamaimperative 2y ago
        There's nothing about identifying and solving one problem at a time that prevents one from taking a holistic approach. In fact the entire point is to interpret the behavior of the entire system in order to find the right singular intervention. To find the true globally optimal point of intervention, one must look at the entirety of the system.
        2y ago
- PaulKeeble 2y ago
  Usually "optimisation" is something that happens once a slow part of the system has been identified. So you develop data and expose the problem with a profiler and fix a few things that seem to be holding it up and then find the next stage of bottlenecks. You keep doing this until you meet your performance goal or you can't improve it any further and determine a completely different approach is required. Personally I prefer to recognise those components ahead of time and think about performance and do experiments to start from an architecture that has a better chance of succeeding in its performance goals from the outset. So I tend to agree with the article that its much more effective to optimise at the architecture than the individual components but its also much harder to do that once the thing is built and working already and the same is likely true for a lot of organisations as well. Once organisational culture has been set its hard to fix it.
  - drewcoo 2y ago
    > Usually "optimisation" is something that happens once a slow part of the system has been identified I wonder if that's because speed is easy to measure. It's certainly not the only thing that can be optimized.
  - ZoomerCretin 2y ago
    Finding and fixing the one and only source of poor performance is a minority of optimizations. The more common case is a lot of suboptimal code creating poor performance.
from-nibly 2y ago
Next read "the goal" by Eli Goldrat
jijojohnxx 2y ago
Solid analysis. Room for improvement?
nicbou 2y ago
On the other hand, this might require an overhaul that the company can't afford. Retooling is not cheap. In many cases, you have to redesign in place, so that only progressive changes are possible. Much has been written about failed overhauls. Even a great idea can fail because it's hard to run an old system and its replacement at the same time.
donatj 2y ago
> A company could put a top man at every position and be swallowed by a competitor with people only half as good, but who are working together. I don't disagree, but I really hate that it's not wrong. It keeps me up at night, frankly. The seemingly most successful companies I have worked for have had tons of the most incompetent people doing the most bureaucratic bullshit. I'm not sure it can be blamed on "synergy" though as much as bureaucracies liking to give money to other bureaucracies making the whole thing a self supporting bureaucratic ecosystem. I'm not sure if it should be taken as something to reach for as the article implies or a cautionary principle. Given the choice I'd certainly rather work for the first company.

40 points by max_ 2y ago

> And the organization suffers even while improving results of components One properly and three half-flat tires on a car is an obvious visual here. The counter-argument is that one must begin somewhere; waiting until everything is "chef's kiss" might mean much waiting.

andsoitis 2y ago

Related concept: you usually make a tradeoff when designing for a resource constraint. Once the resource constraint is removed, you’re still paying the cost but no longer get the benefit of the tradeoff.

apantel 2y ago

I just want to make a comment about optimizing applications even though the article is about optimizing organizations: The way to arrive at the optimal system is to continually optimize all individual components as the system develops. You have to walk the razor’s edge between “premature optimization is the root of all evil” and not optimizing anything until it’s too late and a bunch of bad design decisions have been baked in. If you want to write the fastest program, profile its performance from the start and try different ways of doing things at each step of the process. There’s usually a way of doing things that maximizes simplicity and performance at the same time because maximum performance == doing as little work as possible to complete a task. Chances are that ‘littlest amount of work’ will be elegant.

llamaimperative 2y ago
Ehhh this isn’t quite the right takeaway, or at least it’s contrary to Deming’s approach. The key insight from Deming’s work is that at any given moment there is only and exactly ONE thing that should be optimized. Once you optimize that, there will be a new SINGLE thing that is now slowing down the entire system, and must be optimized. The goal of an engineer of a system (or manager of an org) is to develop a method to repeatedly identify and improve each new bottleneck as it appears, and to ignore other components even if they’re apparently not performing as well as they could.
- Jensson 2y ago
  That is what everyone currently and we know the results, that only takes you from horribly slow to very slow. In order to have a chance to get anywhere close to fast you need each component to already be very fast, and then you can build a fast system on top of those. When you work with slow components you wont use the right architecture for the system, instead you start working around the slowness of each component and you end up with a very slow mess. Example: A function call is slow, it calls a thousand different things so you speed this up by putting a cache in front, great! But now this cache slows down the system, instead you could have sped up the function calls execution time by optimizing/trimming down those thousand things it calls. Adding that cache there made you get further away from a fast system than you were before, not closer. One cache is negligible, but imagine every function creating a new cache, that would be very slow and basically impossible to fix without rewriting the whole thing.
  - rudasn 2y ago
    OK so the cache is the one thing, and the next most expensive "little thing" is the one thing to focus on next?
    - Jensson 2y ago
      But removing the cache makes the system slower, it didn't optimize anything. So no, fixing this isn't possible with that approach, you need to take the holistic approach.
      - llamaimperative 2y ago
        There's nothing about identifying and solving one problem at a time that prevents one from taking a holistic approach. In fact the entire point is to interpret the behavior of the entire system in order to find the right singular intervention. To find the true globally optimal point of intervention, one must look at the entirety of the system.
        2y ago
PaulKeeble 2y ago
Usually "optimisation" is something that happens once a slow part of the system has been identified. So you develop data and expose the problem with a profiler and fix a few things that seem to be holding it up and then find the next stage of bottlenecks. You keep doing this until you meet your performance goal or you can't improve it any further and determine a completely different approach is required. Personally I prefer to recognise those components ahead of time and think about performance and do experiments to start from an architecture that has a better chance of succeeding in its performance goals from the outset. So I tend to agree with the article that its much more effective to optimise at the architecture than the individual components but its also much harder to do that once the thing is built and working already and the same is likely true for a lot of organisations as well. Once organisational culture has been set its hard to fix it.
- drewcoo 2y ago
  > Usually "optimisation" is something that happens once a slow part of the system has been identified I wonder if that's because speed is easy to measure. It's certainly not the only thing that can be optimized.
- ZoomerCretin 2y ago
  Finding and fixing the one and only source of poor performance is a minority of optimizations. The more common case is a lot of suboptimal code creating poor performance.

from-nibly 2y ago

Next read "the goal" by Eli Goldrat

jijojohnxx 2y ago

Solid analysis. Room for improvement?

nicbou 2y ago

On the other hand, this might require an overhaul that the company can't afford. Retooling is not cheap. In many cases, you have to redesign in place, so that only progressive changes are possible. Much has been written about failed overhauls. Even a great idea can fail because it's hard to run an old system and its replacement at the same time.

donatj 2y ago

> A company could put a top man at every position and be swallowed by a competitor with people only half as good, but who are working together. I don't disagree, but I really hate that it's not wrong. It keeps me up at night, frankly. The seemingly most successful companies I have worked for have had tons of the most incompetent people doing the most bureaucratic bullshit. I'm not sure it can be blamed on "synergy" though as much as bureaucracies liking to give money to other bureaucracies making the whole thing a self supporting bureaucratic ecosystem. I'm not sure if it should be taken as something to reach for as the article implies or a cautionary principle. Given the choice I'd certainly rather work for the first company.