Eh... Companies that produce widgets don't generally do so on demand. They over produce when the demand is low, and then fill orders from storage when demand is high. The average-ness averages out over time. (Unless the demand is initially high and then falls, but that's a different conversation.)
But when dealing with programmers, it's a whole different scenario. Let's run through the 5 programmers, 5 parallel tasks scenario again.
You give out 5 parallel tasks to 5 programmers and expect them to be finished in 3 days average. That means some finish early and some finish late. The ones that finish early don't sit on their hands. They get another task, or they start helping one of the slower programmers, if possible. (To be fair, the late task might not be because they are 'slow', but there might have been complications. We aren't assigning blame here.) There is never a situation where the demand for programming work is less than the supply when you're running a programming shop. If there is, you'd let someone go until there isn't.
In programming, everything is late because people under-estimate. Estimates have a built-in assumption that things go well, even when you try to estimate that things don't. The only way to build-in estimates for problems is to badly over-estimate, and those would be useless estimates. (Assuming, of course, that you don't already think they're useless.)
There are other factors, too, like wanting to please your boss with good numbers, etc... But I don't think they're nearly as strong.
So things are always late because of estimates, not because of some 'flaw of averages' or something.
But when dealing with programmers, it's a whole different scenario. Let's run through the 5 programmers, 5 parallel tasks scenario again.
You give out 5 parallel tasks to 5 programmers and expect them to be finished in 3 days average. That means some finish early and some finish late. The ones that finish early don't sit on their hands. They get another task, or they start helping one of the slower programmers, if possible. (To be fair, the late task might not be because they are 'slow', but there might have been complications. We aren't assigning blame here.) There is never a situation where the demand for programming work is less than the supply when you're running a programming shop. If there is, you'd let someone go until there isn't.
In programming, everything is late because people under-estimate. Estimates have a built-in assumption that things go well, even when you try to estimate that things don't. The only way to build-in estimates for problems is to badly over-estimate, and those would be useless estimates. (Assuming, of course, that you don't already think they're useless.)
There are other factors, too, like wanting to please your boss with good numbers, etc... But I don't think they're nearly as strong.
So things are always late because of estimates, not because of some 'flaw of averages' or something.