> Total length of the coastline of the Pacific Ocean
Coastlines are fractal. If your measuring stick is 1 km long, you'll get one number. If it's 1 m long, you'll get a much larger result. And if it's 1 cm long, you'll get an even larger result.
https://en.wikipedia.org/wiki/Coastline_paradox
The actual length of a coastline is infinite when measured with an infinitesimally small measuring stick.
Software development effort also increases, unbounded, as discovery proceeds and the precision of requirements increases.
>In actuality, the concept of an infinite fractal is not applicable to a coastline; as progressively more accurate measurement devices are used
The notion of the length of the coastline, and why I think the question is apt as well, is that regardless of the fractal paradox, the practical answer is that there is an answer that is accurate enough to satisfy the business's or the customer's needs.
The analog for software projects, from my point of view, is scope, and it's generally one of the biggest problems with projects that take too long. Product and various stakeholders take outline broad, high-level scope requirements that may or may not actually be informed by the realities of building or delivering that piece of software. They generally kick the can down the road and take a "I'll know it when I see it" type approach that winds up drastically changing things at some arbitrary point later on on the project.
A rough measuring stick for scope always means that the answer will be longer, however, small measuring sticks for scope are absolutely impractical. What's needed is the understanding from the business that refining scope increases development time, and the high-level broad scope that is sufficient at the beginning of the project is not sufficient at the end. Many businesses want to run with the assumption that their broad scope and the estimates that go with them are accurate enough to bring a product to market.
I’ve gained some experience and confidence at this in the years since, but at the expense of some psychologically painful experiences and a firing. Our industry really calls out for a more basic book aimed at University CS grads (or bootcamp grads or MOOC)-grads on how to estimate tasks.
I think out of 15 people nobody got more than 1 or 2 right, except for my manager, who somehow got about 8 right. I'm curious how the HN crowd does on this - care to post your scores?
Going to read it. thanks.
The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates... please don't look at the answers, I guarantee you will have fun completing it.
For clients, my preferred approach is to show "The Cone of Uncertainty" and ask where they think they are. Since most people have no idea what they want to built I ask if its ok if my estimates are 4x off. That usually gets me a few weeks of peace while a team comes up with a product definition and we start all over again :)