[artworx]

I highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers.

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 :)

[panarky]

That quiz has an unintentionally apt question.

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

[polygotdomain]

>The actual length of a coastline is infinite when measured with an infinitesimally small measuring stick.

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

[gizmo686]

The practical answer is that the question is ill posed, and you need to clarify what is actually being asked. A reasonable way to answer the question as asked would be to model the coastline as a fractal, which would give you an estimated length of infinity. What is needed is not a better way of estimating the answer to the question as asked, because the answer to that question is not useful. Instead, what is needed is a better question (which would require knowledge of why the question is being asked).

[afarrell]

I started reading that book in 2014, but put it down because it really was about project-level estimation on the order of a few weeks to a few months. At the time, I was really looking for guidance on how to estimate tasks—things on the order of a few hours to a couple days.

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.

[mekane8]

A big +1 for this book. I read it with the team of developers I managed (at a consulting company, where estimates directly made the difference between profit and loss on projects) and we found it very useful. It got us to quit using "gut" estimates quite so much and to always keep an eye out for actual data or at least things to count.

[aaaaaar]

Thank you for posting this - I took this quiz a few years ago in a team exercise and all of my answers were off. Since then I wanted to find a copy of this test, but didn't know where to look.

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?

[miluoshi]

I got 6 right. For another 2 incorrect estimates an edge of my estimated range was very close to the correct answer. I think the key is not to try giving too narrow estimates and think in logarithmic scale. If it was possible I tried to decompose a problem to smaller pieces and calculate my estimate from information known to me (i.e. radius/circumference of the Earth for geographic questions) and make a range out of it by adding/taking couple of zeroes from my original estimate.

[naavis]

I just started reading the same book. Seems really nice so far!

[joshdance]

link to the book - https://amzn.to/2IpTNw2

Going to read it. thanks.