Kitchen Cabinet

Imagine a scenario where you’re helping a friend pack up their kitchen:

  • The kitchen contains 10 cabinets.
  • A cabinet takes one hour to pack.
  • However, each cabinet may have a further cabinet nested within it. And on ad infinitum.
  • There is a 1:5 chance of a cabinet containing another cabinet.

How long should you estimate for the job? (The answer is below)

This was suggested in a Hacker News comment discussing software estimation, and struck a chord with many readers. It’s clear that we are no longer in the Fill-The-Bucket domain anymore; our original intuitions about how long things might take are not going to work here.

As a developer, this ‘feels’ more real to me than Fill-The-Bucket. Any task I take on has an outside chance of telescoping into something much worse. Here’s a recent example:

  • I wanted to test out a CSS change to my website site. 1 hour?
  • But in order to avoid wrecking the live version, I would need to test this offline, with Jekyll. 2 hours?
  • However, this meant getting Jekyll working locally on my mac (again). 3 hours
  • However, Jekyll didn’t install, because it used a later version of Ruby than the one I had. 4 hours?
  • The Ruby version Manager (RVM) I had was out-of-date, and needed updating. 5 hours?
  • And I couldn’t update it because brew has been disabled by an update to my OS-X installation. ??? hours

All-in-all, it just may not have been possible for me to test that CSS change the way I wanted to. Every task had a further, worse sub-task embedded within it.

Cabinets within cabinets.


There is no guaranteed end-point for this work, but in the case described above, you could end up moving 70 cabinets if you were unlucky. Have a play with the simulator here, and see how different numbers of cabinets and probabilities work out. In particular, what happens when:

  • You have a single cabinet in the original kitchen?
  • You have thirty cabinets in the original kitchen?

When the number of initial cabinets is low, the distribution tends towards the Exponential Distribution, and it works in a way similar to radioactive decay. That is, we might best be able to talk about moving kitchens in terms of their half-lives. That is, given a bunch of infinity-cabinets, we could say how long it would usually take for half of them to be completed. Then, it’ll be the same again for the next half, and so on.

Whereas Fill-The-Bucket was defined with a mean and variance, the exponential distribution is modelled with a single parameter, lambda (λ).

–> note that all equations between these tags will not need escaping!

Risk In An Exponential World

Let’s assume that the exponential distribution does model software development. Where does that leave us with respect to estimating?

As a developer, I might (if pushed to estimate the project as a single number) pick the half-life point on the graph. On average, half the projects would be complete before this point, and half after.

The problem with that is, the ones that finish later might finish much, much later. Picking the half-life point might be a dangerous strategy. i.e it wouldn’t minimize risk.

As a project manager, I might consider that being late is a bigger risk than being early. Hence the idea of padding estimates.

Being late (i.e. a too-early estimate) risks:

  • Broken Promises, Damaged Reputation Trust Risk Personal
  • Being Fired for bad management. Funding Risk Personal
  • Missing critical dates that co-ordinate with other teams. Coordination Risk Business
  • Project failure Personal, Business.

But being early (a too-late estimate) risks:

  • Wasted developer time Funding Risk Business
  • Parkinsons’ Law (Gold Plating) Complexity Risk Business
  • Estimate was too long, people go elsewhere Personal

As a project manager, you’re much more likely to put your own interests ahead of the company. But luckily, the goals of the company and the project manager co-incide for the most part: managers are incentivised by pay (and maybe bonuses) to bring projects in on time, and doing so looks good on the CV.

Nevertheless, you would expect them to estimate things in a way that benefits their own risk profile, over the company’s.

Also, this offers some explanation of Aranda and Easterbrook’s Result.

A Trick

Offering an estimate transfers risk.

Next Destination

So far, we’ve seen two kinds of estimate: Fill-The-Bucket and Kitchen-Cabinet. Now, it’s time to review a third - estimating Journeys

Add Your Star On GitHub to receive an invite to the GitHub Risk-First team.

Rob Moffat
Rob Moffat Author of Risk-First Software Development. Developer. Working in the UK.