霍夫施塔特定律
事情总是比预期耗时更久，即使你已经把霍夫施塔特定律考虑在内。
显示原始英文内容
Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
Takeaways
- Humans are generally bad at estimating how long tasks take, especially in complex projects. Even when we know we're bad at it, we still underestimate.
- There are always unknowns and complexities that reveal themselves during implementation, extending the timeline.
- Include contingency buffers in schedules, but even those buffers often get consumed.
- Don't be overly optimistic in planning. Acknowledge that delays happen and factor that into timelines and expectations.
Overview
This recursive law captures the paradox of estimation. No matter how much experience we have, projects tend to run late. Even if you say, "This might take 2x longer than I think," it might still take 3x. It highlights the inherent uncertainty in complex creative work, such as software development. There are often hidden tasks, unplanned integration issues, or requirement changes.
In practice, Hofstadter's Law explains why techniques like padding estimates, awareness of Parkinson's Law, and the use of historical data are essential, yet surprises still occur.
It pairs with Parkinson's Law as a caution: don't pad too much (Parkinson will waste time), but also don't be naive (Hofstadter will bite you with delays).
Examples
Virtually every software project can serve as an example. A team plans a new feature expecting it to take one month. They factor in potential delays and say six weeks to be safe. It ends up taking three months, sometimes even six months later. Why? Integrating with an API was harder, a key developer got sick, or the first approach failed and had to be redone. The unexpected became the norm.
A practical rule of thumb: if it takes 2 minutes, do it now. If it takes a few minutes, call it 1 hour. If it takes a few hours, call it 1 day. We are not working to prove speed, but to buy enough space to ship well.
Origins
Douglas Hofstadter created this law in 1979 in his book "Gödel, Escher, Bach: An Eternal Golden Braid". The book explores themes of recursion and self-reference, making this recursive law a fitting example.
In software engineering, Fred Brooks' observation "everything takes longer than it takes" from The Mythical Man-Month has a similar meaning. The law has become common among developers who've all experienced projects that overshoot schedules.
核心含义
软件工作包含探索、返工、协作和未知依赖，而估算通常基于“事情按计划进行”的故事。即使团队知道自己容易低估，新的不确定性仍可能让计划失真。
改善估算不能只加一个固定缓冲，更应该拆分任务、尽早验证风险，并持续用实际数据校准预测。
实践例子
一个功能看起来只需三天，但开发中发现要兼容旧数据、协调另一个团队并补齐监控，最终花了两周。问题不一定是个人懒散，而是计划没有包含探索成本。
来源与边界
Douglas Hofstadter 在《哥德尔、埃舍尔、巴赫》中提出这句带有自指意味的话。它提醒人们尊重不确定性，但不能成为停止估算和复盘的借口。