4 ms·

I think I've heard this in reference to the difficulty of software estimation. The project details and potential problems are unknowns until you get to that spe

by ilaksh 3y ago

I think I've heard this in reference to the difficulty of software estimation. The project details and potential problems are unknowns until you get to that specific part of the project. Even though theoretically you can see the "shape" and rough size of the project when zoomed out.

valyagolev 3y ago
you also should, and inevitably will, cut corners smaller than your "step" when actually following the "coastline" in development. the more fixated one on the smallest details, the longer it will end up
chrisweekly 3y ago
Yes, there's a classic blig post (sorry, no bookmark handy) about an analogous trip from SF to LA.... Also, (maybe counterintuitively), in software estimation the more fine-grained the estimates, the more likely they are to _underestimate_ project scope. For areas that are better-understood, the estimate will be (properly) limited in scope (reducing the overall buffer) -- which leaves less margin for error in the areas with more unknowns, where the biggest scope bloat is hiding. As a rule, software estimates should use a very broad brush. (This also helps mitigate the tendency of PHBs and product owners to mistake precision for accuracy.)
- kqr2 3y ago
  https://techcrunch.com/2016/04/30/estimate-thrice-develop-once/ https://techcrunch.com/2016/04/30/estimate-thrice-develop-on...
  - skrebbel 3y ago
    Woa, from way back when a traffic sign with the word “Estimate” was considered helpful imagery
  - chrisweekly 3y ago
    Thanks, yes - that's the one. (Too late for me to correct "blig" -> "blog", whoops.)
082349872349872 3y ago
Schröder's Fractals, Chaos, and Power Laws had a digression about a family of distributions where the longer you've gone without observing something, the longer the expected mean time to first sighting becomes. I read that and immediately thought well, this explains software schedule slips. "The first 90% took us 90% of the scheduled time; the last 10% will take the other 90%..." (editor's note: 9% of that last 10%, anyway!)
honzabe 3y ago
> I think I've heard this in reference to the difficulty of software estimation. I don't like linking to Quora but I have to link the legendary "coastline trip" story posted by Michael Wolfe as a response to the question "Why are software development task estimations regularly off by a factor of 2-3?" https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3 https://www.quora.com/Why-are-software-development-task-esti...
heavenlyblue 3y ago
It's delusional. The only reason this is a problem in mathematics is because lines in mathematics are infinitely narrow, while in reality complexity is bounded. In real life, specific unknowns in part of the project may turn out to be actually _easier_ than you thought, while in perimeter calculations it's always a lower bound at a higher scale.
deleted 3y ago
[deleted]

by ilaksh 3y ago

valyagolev 3y ago

you also should, and inevitably will, cut corners smaller than your "step" when actually following the "coastline" in development. the more fixated one on the smallest details, the longer it will end up

chrisweekly 3y ago

Yes, there's a classic blig post (sorry, no bookmark handy) about an analogous trip from SF to LA.... Also, (maybe counterintuitively), in software estimation the more fine-grained the estimates, the more likely they are to _underestimate_ project scope. For areas that are better-understood, the estimate will be (properly) limited in scope (reducing the overall buffer) -- which leaves less margin for error in the areas with more unknowns, where the biggest scope bloat is hiding. As a rule, software estimates should use a very broad brush. (This also helps mitigate the tendency of PHBs and product owners to mistake precision for accuracy.)

kqr2 3y ago
https://techcrunch.com/2016/04/30/estimate-thrice-develop-once/ https://techcrunch.com/2016/04/30/estimate-thrice-develop-on...
- skrebbel 3y ago
  Woa, from way back when a traffic sign with the word “Estimate” was considered helpful imagery
- chrisweekly 3y ago
  Thanks, yes - that's the one. (Too late for me to correct "blig" -> "blog", whoops.)

082349872349872 3y ago

Schröder's Fractals, Chaos, and Power Laws had a digression about a family of distributions where the longer you've gone without observing something, the longer the expected mean time to first sighting becomes. I read that and immediately thought well, this explains software schedule slips. "The first 90% took us 90% of the scheduled time; the last 10% will take the other 90%..." (editor's note: 9% of that last 10%, anyway!)

honzabe 3y ago

> I think I've heard this in reference to the difficulty of software estimation. I don't like linking to Quora but I have to link the legendary "coastline trip" story posted by Michael Wolfe as a response to the question "Why are software development task estimations regularly off by a factor of 2-3?" https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3 https://www.quora.com/Why-are-software-development-task-esti...

heavenlyblue 3y ago

It's delusional. The only reason this is a problem in mathematics is because lines in mathematics are infinitely narrow, while in reality complexity is bounded. In real life, specific unknowns in part of the project may turn out to be actually _easier_ than you thought, while in perimeter calculations it's always a lower bound at a higher scale.

deleted 3y ago

[deleted]