

The Flaw of Averages, and Why Everything is Late - xel02
http://arandomforest.com/?p=234

======
wccrawford
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.

------
RiderOfGiraffes
Related: <http://news.ycombinator.com/item?id=1705098>

