Corporate life · Murphy's laws
Hofstadter's Law: Why the Buffer Disappears
The short version: in a chain of tasks, lateness adds up but earliness usually doesn't, because nobody hands work over early. In our simulation of 10 tasks planned at 5 days each, 60% of tasks individually took less than 5 days. If early finishes were passed on, the project would finish on time 60% of the time. If they're lost, it finishes on time 0.7% of the time, about 7 days late on average. Padding every task by 30% only lifts that to 14%, because the padding gets used up too. That's Hofstadter's law in numbers: even the correction is eaten.
Last time, the project ran late. So this time Kevin's boss has added a 30% buffer to every task. "Hofstadter's law," he announces, "has been taken into account."
Each task is now planned at six and a half days instead of five. Each task now takes six and a half days, or more. The project is late again. Kevin has quietly reread the law, which says this will happen even when you take it into account.
The law
Douglas Hofstadter wrote it in his 1979 book Gödel, Escher, Bach: it always takes longer than you expect, even when you take into account Hofstadter's law. It's a joke about recursion, and a sharp observation about plans. Its relative, the planning fallacy, says we underestimate; Hofstadter's version says the correction underestimates too.
Where the time goes
We simulated a project of 10 tasks done one after another, each planned at 5 days, 50 days in all. Each task's real length varies: it's usually a bit shorter than planned, sometimes much longer. In our model, 60% of tasks finish early on their own. The question is what happens to that early finish.
| What happens to time saved | Plan | Finishes on time | Average length |
|---|---|---|---|
| Early finishes are passed on | 50 days | 60% | 49 days |
| Early finishes are lost | 50 days | 0.7% | 57 days |
| Lost, with 20% buffer on each task | 60 days | 7% | 64 days |
| Lost, with 30% buffer on each task | 65 days | 14% | 68 days |
| Lost, with 50% buffer on each task | 75 days | 35% | 77 days |
Early finishes get lost for ordinary reasons: the next person isn't ready to start, the work gets polished until the deadline, or nobody wants to admit a task was over-estimated and lose the slack next time. Late finishes, meanwhile, always push everything after them. That asymmetry turns a plan that's right on average into one that's almost always late. The buffer doesn't break the asymmetry; it just moves it.
Chance a 10-task project finishes on time
What actually helps
- Pass time on. Hand work over as soon as it's done, and let the next task start early.
- One shared buffer, not many small ones. A single reserve at the end of the project, used only when a task runs over, isn't eaten task by task.
- Plan with a range. Look at how long similar projects really took, and plan for the spread, not the average.
Statistics for noobs: averages don't add up in a chain
The expected value of a chain is the sum of the averages only if every gain is kept as well as every loss. When early finishes are thrown away and late ones are passed on, each step becomes "the planned time or more", and the total drifts upwards. Lopsided rules turn fair estimates into late projects.
Where it costs you money
The same asymmetry hits investors who take profits early but let losses run: small wins are cashed in, big losses are kept, and an average that should be positive drifts negative. Look at what happens to the good outcomes, not just the bad ones.
The moral
For the next project, Kevin suggested one shared buffer at the end instead of padding each task. The boss approved it, then added the shared buffer and kept the 30% on each task, "to be safe". The project is planned at 80 days. Kevin's model gives it a good chance of finishing in about 70, which nobody will ever find out, because everyone now has until day 80.
What this model can't tell you
- Our task lengths are a model. Real tasks may vary more or less; the asymmetry is what matters.
- Not every team loses early finishes. Teams that hand work over immediately can beat their plans, as the first row shows.
- Tasks aren't always in a chain. Parallel tasks behave differently, though the last one to finish still sets the date.
Kevin's boss and the buffers are an illustration. Hofstadter's law comes from Douglas Hofstadter's book Gödel, Escher, Bach (1979). The figures come from our own simulation of 200,000 projects of 10 sequential tasks, planned at 5 days each, with log-normal task lengths (median 4.5 days). Educational content, not business or financial advice.