I believe that those first explanations and graphics are missing an important aspect. The step in the burger-cooking process that takes the longest is the grilling step, during which the cook does nothing but wait for the burgers to finish cooking. The cook cannot speed up the process by focusing on only one burger at a time instead of both. Even without all of the math on batch processing that is presented later in the article, the idea that it would take 12 minutes to cook three burgers while it only takes 4 minutes to cook one is not plausible.
Do you think you're considering the burger metaphor, ie the type of task, and not letting the point of the article stay front and center? I think we can agree that not all development tasks are the same, but I think the premise of first in first out is better than large bulk concurrent tasks, which I thought was the premise of the .
A real world example of the waiting to cook metaphor is PR review and client/QA validation.
Imagine you’re working on an integration project where you use an API provided to you by a third party, there will be a point where you coded a client, you made the calls, and you’ll need their validation before moving that specific task further. And when they green light your implementation, you send that to QA which will review your feature in their next batch.
If you consider your task completion to be “have the service integrated in production”, you have least two stopping points where focusing more on your task won’t help you go faster.
The optimal move is to plan for those and fill the gap. It becomes trickier when it’s unplanned: you were expecting for something to work, but you’ll need to wait for a bugfix that will only comes in X weeks, for instance.
