Hofstadter’s Law states: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” The line comes from Douglas Hofstadter’s 1979 book Godel, Escher, Bach: An Eternal Golden Braid, where it appears in a discussion of how hard it is to predict how long a complex task will take. The book is the primary source; the law was not coined in a software context at all, but in a passage about the difficulty of estimating when a chess program would be able to beat its creators.
The structure of the law is what makes it more than a quip. It is self-referential: it refers to itself in its own statement, so that even building the correction for chronic underestimation into your estimate is not enough, because the correction is itself subject to the same underestimation. The joke encodes a real and unsettling point about recursive reasoning, which is a central theme of Godel, Escher, Bach. You cannot escape the bias simply by knowing about it, because your adjusted estimate is just another estimate.
Software engineering adopted the law almost immediately because it describes the lived experience of nearly every project. Schedules slip not only because of unforeseen problems but because the act of estimating is itself optimistic by nature. Even teams that pad their estimates to account for past slippage find that the padded estimates slip too. The law sits naturally alongside Fred Brooks’s observations in The Mythical Man-Month about why software projects run late and why adding people to a late project makes it later.
Part of the law’s durability is that it offers no remedy. It is not actionable advice; it is a description of a trap. There is no number you can multiply your estimate by to make it accurate, because whatever you multiply by, the law applies again to the result. The best practitioners take from it is humility: treat estimates as ranges, build in slack you expect to consume, and distrust any plan that assumes everything will go to plan.
The law has spread far beyond computing into project management, construction, and everyday planning, which is fitting for a principle that was never really about programming in the first place. It endures because it is funny, true, and impossible to fully outsmart, which is exactly the kind of recursive paradox Hofstadter built his book around.