that "solution" is, basically, ridiculous and not adopted for good reason.
A quote from Michael O'Church I quite like:
Let's say that you have 20 tasks. Each involves rolling a 10-sided die.
If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15
minutes. If it's a 10, wait an hour.
How long is this string of tasks going to take? Summing the median time
expectancy, we get a sum 110 minutes, because the median time for a task is
5.5 minutes. The actual expected time to completion is 222 minutes, with 5+
hours not being unreasonable if one rolls a lot of 9's and 10's.
This is an obvious example where summing the median expected time for the
tasks is ridiculous, but it's exactly what people do when they compute time
estimates, even though the reality on the field is that the time-cost
distribution has a lot more weight on the right. (That is, it's more common
for a 6-month project to take 8 months than 4. In statistics-wonk terms, the
distribution is log-normal.)
Software estimates are generally computed (implicitly) by summing the
good-case (25th to 50th percentile) times-to-completion, assuming perfect
parallelism with no communication overhead, and with a tendency for
unexpected tasks, undocumented responsibilities, and bugs to be overlooked
outright.
[1]
The point is, you are unable to know the worst possible outcome. Since it will have huge input into your average, your average is therefore useless. Perhaps the project isn't specced fully enough and, during implementation, a dev discovers an ugly or impossible feature interaction. You now have to either cut features or rearchitect another feature, ie the dice come up 10 in Michael's analogy.
An example from my background: I work on ml code. A learning algorithm was written in parallel with a particular loss function (essentially, this tells you if your estimates are good or bad). The person writing the spec assumed that a different loss function could be dropped in later. Indeed, this is how the math works on paper. But loss function number 2 required a different data layout between the machines. The vision was writing a new loss function should be one or two lines of code dropped into the middle of a hot loop; the reality was it took almost a month of work.
[1] https://news.ycombinator.com/item?id=3522910