Glen Alleman has a great little post about two ways to solve a problem (http://herdingcats.typepad.com/my_weblog/2016/10/making-hard-stuff-into-east-stuff.html)
The story about the mathematician who ‘reduced’ the problem to a known one is funny, and easily recognisable to software developers as well – solve part of the problem and hand the rest to a function library that knows how to solve the revised problem. It is logically sound, even if impractical if taken to the extreme as in the story.
However, it may be too simplistic an example in the argument against #NoEstimates. If you were asked to estimate how long it would take to boil away a potful of water, you might think to revise the problem into looking up (or estimating) how long it would take to boil away a tablespoon of water, and then multiply that by the number of tablespoons of water contained in the pot. In this case, you have reduced the problem into multiple known ones. All that’s left is to combine the results of the solved problem. I don’t know for sure, but I suspect the actual time to vaporise the whole potful will take significantly longer than the sum.
Another thing that makes project estimating hard is the dissimilarity between projects (the ‘uniqueness’ of each project) -- it’s not always about boiling the same volume of water in the same pot. It’s boiling potentially a different volume of a different kind of liquid, using a different kind of pot, using a different kind of heat source, in an area with a different temperature and different air density, with different stakeholder requirements about governance and reporting of the progress.
