Hofstadter's law

Hofstadter's law says: it always takes longer than you expect, even when you take into account Hofstadter's law. Douglas Hofstadter wrote it in Gödel, Escher, Bach (1979), about how long computers would take to play chess well. The recursion is the joke, and the point: knowing that you underestimate doesn't stop you from doing it.

#Why estimates slip

• The planning fallacy. Kahneman and Tversky described it the same year: people imagine the steps of the plan going right and underweight everything that could go wrong.
• Unknown work. You estimate the tasks you can see. The ones you discover halfway (a library that doesn't support your case, a migration nobody mentioned) were never in the number.
• Skewed durations. A task can't finish in less than zero time, but it can take ten times longer than planned. Like tail latency, the long tail dominates: a project of twenty tasks almost always hits at least one bad one.
• Integration. Pieces that each work rarely work together on the first try, and that time is rarely in anyone's estimate.

#Estimating anyway

• Use the reference class. Ask how long the last three similar projects actually took, not how long this one should take. This "outside view" beats careful bottom-up plans.
• Give ranges, not points. "Two to five weeks, most likely three" carries the uncertainty a single number hides.
• Slice small and ship often. Short tasks have short tails, and finishing one tells you how fast you really go.
• Re-estimate as you learn. The estimate made after the first week is worth far more than the one made before it.
• Watch staffing. Throwing people at a slipping date runs into Brooks's law.