3 ms·

Ask how long roughly similar projects in the past have taken. Do not do any specific thinking about the detailed implementation. I'm serious! http://www.over

by Eliezer 18y ago

Ask how long roughly similar projects in the past have taken. Do not do any specific thinking about the detailed implementation. I'm serious! http://www.overcomingbias.com/2007/09/planning-fallac.html http://www.overcomingbias.com/2007/09/planning-fallac.html

JesseAldridge 18y ago
Along these lines, keep a daily log of work you've done. That way you can look back and see how long stuff really takes to get done.
drsnyder 18y ago
I'm beginning to agree with this more and more. Consider something you have done in the past that is similar to the the task at hand and use how long it took as a guide. It also helps if your development cycles are fairly short (i.e. 1-2 weeks and no longer). I have found that it is much easier to estimate how long it will take if the amount of work you are estimating is smaller. Keeping your development cycles short also has the beneficial side effect of reducing the shock factor when you have to double it.
IsaacSchlueter 18y ago
While the planning fallacy is absolutely a problem, the issue is that "roughly similar" is a hard thing to gauge in software development. Unless you're doing fairly repetitive work (cranking out brochure websites for clients, for instance), you shouldn't be doing any "roughly similar" projects! Each thing you do should be brand new—if it wasn't, you'd just reuse the code you already have. That is the perennial dilemma in software estimation. You don't know how big it is until you're halfway done building it. I'm not proposing a solution to this problem, just pointing out that this IS a problem, and probably not one that can be solved in a one-line bit of advice. Saying "cut it up into pieces" or "estimate similar past projects" is like telling a nervous guy to "just be himself" on a first date.

3 ms·

Ask how long roughly similar projects in the past have taken. Do not do any specific thinking about the detailed implementation. I'm serious! http://www.over

by Eliezer 18y ago

JesseAldridge 18y ago
Along these lines, keep a daily log of work you've done. That way you can look back and see how long stuff really takes to get done.
drsnyder 18y ago
I'm beginning to agree with this more and more. Consider something you have done in the past that is similar to the the task at hand and use how long it took as a guide. It also helps if your development cycles are fairly short (i.e. 1-2 weeks and no longer). I have found that it is much easier to estimate how long it will take if the amount of work you are estimating is smaller. Keeping your development cycles short also has the beneficial side effect of reducing the shock factor when you have to double it.
IsaacSchlueter 18y ago
While the planning fallacy is absolutely a problem, the issue is that "roughly similar" is a hard thing to gauge in software development. Unless you're doing fairly repetitive work (cranking out brochure websites for clients, for instance), you shouldn't be doing any "roughly similar" projects! Each thing you do should be brand new—if it wasn't, you'd just reuse the code you already have. That is the perennial dilemma in software estimation. You don't know how big it is until you're halfway done building it. I'm not proposing a solution to this problem, just pointing out that this IS a problem, and probably not one that can be solved in a one-line bit of advice. Saying "cut it up into pieces" or "estimate similar past projects" is like telling a nervous guy to "just be himself" on a first date.