3 ms·

> This is where System 2 comes in—if we performed a more thorough analysis, these factors would have been considered in our answer. Then it would be clear that

> This is where System 2 comes in—if we performed a more thorough analysis, these factors would have been considered in our answer. Then it would be clear that it’s much more likely to take 20 or 30 minutes to run to the store instead of 10. I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a reverse correlation to their accuracy. In other words, their first gut reactions were actually better than estimations given after going in-depth through all the details and sub-tasks.

JohnL4 8y ago
Maybe because people over-rely on a fine-grained breakdown? When I try that, I miss big stuff. Kind fits in with that Fibonacci estimation from Agile, eh?
jcadam 8y ago
> I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a reverse correlation to their accuracy. In other words, their first gut reactions were actually better than estimations given after going in-depth through all the details and sub-tasks. I've noticed this as well. The last few years my 'gut' estimates have tended to be more accurate (and larger) - but since I can't support them with anything other than "Trust me, I've been writing software for over a decade", they're never taken seriously. My guess would be that breaking down a complex software system into sub-tasks (esp. when you are breaking things down within modules) that are too fine grained fails to capture the inter-dependencies between sections of the code-base. So, you complete task A and move onto to task B, then realize you have to revisit the code you wrote during task A because task B is dependent on it and some of your early assumptions were imperfect. And then you need to fix the unit tests you wrote for task A. And so on, and so forth.
- cpeterso 8y ago
  Bottom-up estimation is probably more accurate for the work to be done, but not for other project overhead. Using data from an analogous project to forecast the delivery date would include that overhead.

JohnL4 8y ago

Maybe because people over-rely on a fine-grained breakdown? When I try that, I miss big stuff. Kind fits in with that Fibonacci estimation from Agile, eh?

jcadam 8y ago

> I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a reverse correlation to their accuracy. In other words, their first gut reactions were actually better than estimations given after going in-depth through all the details and sub-tasks. I've noticed this as well. The last few years my 'gut' estimates have tended to be more accurate (and larger) - but since I can't support them with anything other than "Trust me, I've been writing software for over a decade", they're never taken seriously. My guess would be that breaking down a complex software system into sub-tasks (esp. when you are breaking things down within modules) that are too fine grained fails to capture the inter-dependencies between sections of the code-base. So, you complete task A and move onto to task B, then realize you have to revisit the code you wrote during task A because task B is dependent on it and some of your early assumptions were imperfect. And then you need to fix the unit tests you wrote for task A. And so on, and so forth.

cpeterso 8y ago
Bottom-up estimation is probably more accurate for the work to be done, but not for other project overhead. Using data from an analogous project to forecast the delivery date would include that overhead.