Estimation Done Honestly

Stop estimating from your gut. Start estimating from your measured past. Run a three-week estimation log — every meaningful task estimated before starting and logged against its actual — and produce your personal calibration coefficients by task category, a reference-class catalog for the major task types in your work, and a 30-day AI-speedup-or-slowdown distribution. Update continuously as the AI-era variance plays out. Estimation is EXPLAIN ANALYZE on your own work. When a query is slow you don't guess — you look at the actual plan, the actual row counts. Engineers who would never deploy a query without EXPLAIN ANALYZE deploy time commitments without the equivalent measurement, daily, for entire careers. The estimation log is the EXPLAIN ANALYZE; the calibration coefficient is the planner's cost model, finally trained on your actual data. Reference-class forecasting is benchmarking against existing similar code instead of theoretical complexity analysis. The inside-view move enumerates components — controller, model, tests, edge cases — and sums imagined times. The outside-view move recalls the last five structurally similar features and takes the median of their actuals. Senior engineers already trust "this feels like the user-management feature from two years ago" over the component breakdown; the catalog formalizes the instinct into a tool. And the planning fallacy is the optimistic timer: every gut estimate is a happy-path execution, and production sees the p90. Engineers learned to reason about p99 latency instead of averages because the tail determines user experience; the same move applies here — reason about p90 estimates, not point estimates. Most estimation failures are failures to model surface area (the feature plus everything the feature touches); reference classes catch this implicitly, because past actuals already paid the surface-area cost.