4 ms·
> 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 h
by 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 agoBottom-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.