# Hofstadter's law

> It always takes longer than you expect, even when you take Hofstadter's law into account.

Concept · Laws of software engineering · https://levelcode.org/concepts/hofstadters-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](https://levelcode.org/concepts/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.

> [!NOTE]
> **Why it isn't really a law.** It makes no testable prediction: it doesn't say *how much* longer, and its self-reference means any amount of padding can be declared "not enough" after the fact. Doubling every estimate isn't a method either; teams just start filling the extra time. It's a good reminder of a real bias, not a tool. The useful part is the evidence behind it, which points to the fixes below.

## 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](https://levelcode.org/concepts/brooks-law).