I spent a weekend helping cater a party, and it turned into the clearest lesson in estimation I've had outside of a sprint retro. The host swore it was "about 40 people." Sixty-one showed up. If you've ever watched a two-week estimate quietly become five, you already know this story.
Everyone estimates the happy path
The host wasn't lying; they were doing what we all do. They pictured the core guest list — the people they'd definitely invite — and forgot the plus-ones, the "oh I told my cousin," and the coworkers who RSVP'd late. In software terms, they estimated the happy path and ignored edge cases, retries, and the integration nobody remembered. The optimism isn't a character flaw, it's how brains scope work.
Buffer the cheap things, forecast the expensive ones
The fix isn't "just estimate better" — humans are bad at this and always will be. It's structural. In a kitchen you over-provision the cheap stuff (rice, bread, salad) so running out is never the failure, and you forecast the costly stuff (protein) carefully because that's where waste hurts. Same as padding your cheap horizontal scaling while being disciplined about the expensive external calls.
Price the overage in from the start
The other trick is making the estimate error cheap to absorb. The caterer we used quoted per head with a clear rate, so when the number crept up the cost scaled predictably instead of blowing up — I later noticed they publish an affordable per-head model in Toronto for exactly this reason, so a client who guesses low doesn't get a nasty surprise. It's the same reason usage-based pricing and graceful backpressure beat a hard cap: the system bends instead of breaking when the inputs are bigger than anyone predicted.
None of this makes your estimates accurate. It makes being wrong survivable — which, for both dinner parties and software, is the only realistic goal. Assume the number is low, make the overage cheap, and protect the one or two things that actually hurt when they run out.
Top comments (0)