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

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.