Hacker News Reader

Comment by ynniv | Hacker News Reader

At the risk of being a metoo, it should be emphasized that things need to be doubled. I'm not sure why, but I constantly find that things take twice as long as I expect, even after accounting for the fact that things need to be doubled.

It sometimes helps to keep doubling it until it seems funny that it could take so long, and then step back once. ie, "Writing a parser will take a week. Two weeks. Four weeks... weeeeell, probably not four weeks - two weeks it is."

I also like to front-load things that I'm uncertain about, as playing catch-up near your deadline is easier when you have (hopefully over-estimated) well known tasks remaining.

View on HN

I think the doubling comes from the fact that initial estimates are always that it would take x weeks if you were to work flat out 100% of the time. As this is incredibly unlikely to happen, you have to increase the estimate to take into account "overheads" (such as posting here...). I like your "double until it's silly then go back a step" idea; it seems like a good way to get quick estimates.

I try to take into account how accurate my estimates will be: if a sub-task is something I've done alot, I stick with my estimate; if it's something where I think there's a risk of it going wrong I add more time (keeping a note of the estimate and the risk time separately - it makes project managers think you know what you're doing!). I then add them all up, divide by 0.7 (roughly how efficiently I convert booked hours into directly worked hours - the rest is email and meetings etc.). Also, any task where you have to write code that works with someone else's code, I double the estimate.

it sounds like what you are saying is the first estimate is the optimist in us, and until it seems 'funny' that it should take so long, you are giving it a test against the pessimist in you. as entrepreneurs, and creators we probably always 'believe' that something is doable, hence the optimism.

Reply on news.ycombinator.com