[llamaimperative]

I don't find the glass <> IT system analogy compelling (or even sensical) at all.

Describe to me how an IT system can produce results (e.g. tickets closed, if you wish) at a rate higher than the processing rate of the slowest component.

> A perfectly optimized component can't be a bottleneck but can still be the slowest component, trying to optimize that further will not speed up the system at all.

Correct -- but neither will optimizing anything else! That's the whole point!

[Jensson]

> Describe to me how an IT system can produce results (e.g. tickets closed, if you wish) at a rate higher than the processing rate of the slowest component.

It can't, but the slowest component can be perfectly optimized and thus not be a bottleneck. You would fail to find a real bottleneck in this case, since you are just looking for the slowest one, hence I have proven that your statement above was false, there are cases where the optimal strategy is not to just look at the slowest component.

If you have some other definition for bottleneck we can continue, but this "the slowest component" is not a good definition.

[llamaimperative]

No, what you've done is you've failed to find a way to improve the system's behavior further. If you have the slowest component and you can't make it faster, then congrats: you cannot make the system faster.

You cannot build cars faster than you can mine metal, nor faster than you can put stickers on the windows on their way out the factory. You are done optimizing.

[Jensson]

> If you have the slowest component and you can't make it faster, then congrats: you cannot make the system faster.

That isn't true, I can take the next slowest component and make that faster and now the system is faster.

[llamaimperative]

Lol, no! You cannot!

The system's behavior will not change, you will just have wasted money improving the next-slowest component for quite literally no benefit.

Machine A (10 units per hour) -> Machine B (20 units per hour) -> Machine C (15 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (20 units per hour) -> Machine C (20 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (25 units per hour) -> Machine C (20 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (30 units per hour) -> Machine C (20 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (30 units per hour) -> Machine C (100 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (10,000 units per hour) -> Machine C (10,000 units per hour) => Produces 10 units per hour

[Jensson]

That is only true for parallel executions, not serial ones. If a process requires executing many components serially (which happens a ton), then it isn't enough to just look at the slowest component.

Anyway, thanks, now we know that you only considered throughput in a factory like setting, there it is true. But your rule there isn't true for software systems in general, optimizing latency speeds and serial performance is extremely common in software.

Edit: Example:

Machine A takes 1 hour -> B 2 hours : System takes 3 hours.

Machine A takes 0.5 hour -> B 2 hours : System takes 2.5 hours, so faster even though we optimized the faster component.

[llamaimperative]

The example I gave was a serial process. And in fact, every parallel process is just a group of serial processes. Factories are obviously linear but in reality every single process is linear through time, including the chaotic, complex ones you see in IT or software orgs. (Unless you have a time machine, in which case ignore me)

Fastest/slowest doesn't mean "takes the longest in clock time," it means "has the lowest throughput."

In your example, if B is only able to produce something every 2 hours, then no, speeding up A will not increase the throughput. You will see a larger backlog of jobs from A waiting for B to become available. Ultimately only 0.5 units per hour will be produced by this process.

If B is able to produce more than something every 2 hours, e.g. it can produce multiple things in parallel, then yes, speeding up A will increase throughput. But that is only because B wasn't the bottleneck to begin with! Your own failure to serialize that parallel process hid that fact from you.

Either of your systems (unless you have invisible parallelism in B) will produce 0.5 units per hour.

If you're saying to yourself, "well this is a process that runs only once per day, so there's no backlog anywhere in here," then congrats: you've just discovered that the true constraint sits upstream of A!

Speeding this up might be a nice quality of life improvement for the people involved, but it will not yield different outcomes for the system as a whole, because there's not enough work coming into A to consume the capacity of B anyway.