Hofstadter's Law: Six Months. Then 12. Then 18. Then 24.

A migration planned for a small team and six months took everyone we had, for two years. It wasn't a single miss: the six months became twelve, then eighteen, then twenty-four. Every revision was made by people who already knew the last estimate was wrong, and each of the first three was wrong anyway. The fourth one held. This episode is about why the first three were wrong and what was different about the fourth. It starts with Hofstadter's Law, from Douglas Hofstadter's 1979 book Gödel, Escher, Bach: it always takes longer than you expect, even when you take into account Hofstadter's Law. Then the planning fallacy, and a well-known study in which students predicted their thesis would take about thirty-four days and took about fifty-five, with roughly three in ten finishing when they said they would. Those students were looking at their own work from the inside, and the inside view runs optimistic. But a student's estimate is only a guess about themselves. Ours came with a date attached. An estimate made to fit a date isn't a forecast, it's a target in a forecast's clothes, and researchers who study why big projects overrun separate two causes: optimism, and a number shaped by what will win approval. The remedies are not the same. The knowledge to get the number right existed in the room. What was missing was any route for it to reach the number. Then why nobody stopped. A mature warehouse can't be made smaller, and while both platforms ran we paid for both, so the usual advice, don't throw good money after bad, assumes a stop button that wasn't there. What happened instead was quieter: the scope grew, people were pulled in from other teams, and each slip was presented as a widening, never as a new commitment that someone had to approve again. So what is this costing, and who is paying for it, never got asked out loud. What was different about the fourth estimate was its source, not its date. People who had done this kind of work brought evidence about what it takes and how many people it takes, and managers from other teams who needed the roadmap scrutinized the plan. That is the outside view: instead of asking how this one will go, ask how the ones like it went. The inside view gave us six months. The outside view gave us twenty-four. The confidence of a promise should never exceed the confidence of the knowledge behind it. The episode ends with four things you can do before anyone says the first number out loud: start from the outside view; give a range and write down what it depends on, committing to the end you can't afford to miss and treating the other end as the stretch; make every extension a re-approval, not an announcement; and have someone outside the chain read the estimate before it becomes a commitment. The less you can stop a project, the more the estimate is worth, so spend the care up front, while the number is still cheap to get right. Along the way, a note on AI: the six-month promise is coming back with a new engine in it. A 2025 randomized trial by METR (sixteen experienced open-source developers, 246 tasks) found developers expected AI tools to make them about 24% faster, measured about 19% slower, and afterward still believed they had been about 20% faster. It is one small trial on early-2025 tools and a larger 2026 follow-up had wide error bars, so the honest summary is that how much it helps is still being measured, which is the point: when the people doing the work can't tell from the inside, ask for the outside view. Sources: Douglas Hofstadter, Gödel, Escher, Bach (1979). Roger Buehler, Dale Griffin and Michael Ross, "Exploring the planning fallacy," Journal of Personality and Social Psychology (1994). Bent Flyvbjerg, "From Nobel Prize to Project Management: Getting Risks Right," Project Management Journal (2006). Mark Keil and Daniel Robey, "Turning Around Troubled Software Projects," Journal of Management Information Systems (1999). METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025). Subscribe to The Foundation Layer for more on why the data and AI problems your org keeps hitting are usually the same problem wearing a new name. WATCH NEXT • Platform Migration: Why Every One Is a Shell Game:    • Platform Migration: Why Every One Is a She...   • Chesterton's Fence: 'We've Always Done It This Way':    • Chesterton's Fence: 'We've Always Done It ...   • The full series, in order:    • The Foundation Layer: Full Episodes