Matt Pavelle

The Bike Shed Analogy

Or, "tell me quickly why my meetings take so long".

Disproportionate resources are spent on trivial issues

As Parkinson elucidated in 1957, organizations give disproportionate weight to trivial issues. "The time spent on any item of the agenda will be in inverse proportion to the (monetary) sum involved."

Famously, a nuclear reactor is used as an example because it is so expensive and complicated that an average person cannot comprehend it, so they assume that those working on it understand it, and so it will often be a minimal topic of discussion. Additionally, even people with strong opinions on a complicated subject will often withhold them for fear of being shown to be insufficiently informed.

On the other hand, everyone can comprehend the costs and function of a bicycle shed, so planning one can result in endless discussions as everyone involved wants to provide input and show that they have contributed.

This is also famously relevant in software, as noted in the a post to freebsd-hackers on October 2, 1999 after a very long argument about whether sleep(1) should take fractional second arguments.

Why should I care what color the bikeshed is?

"What is it about this bike shed?" Some of you have asked me.

It is a long story, or rather it is an old story, but it is quite short actually. C. Northcote Parkinson wrote a book in the early 1960s, called "Parkinson's Law", which contains a lot of insight into the dynamics of management.

<< snip a bit of commentary on the book >>

In the specific example involving the bike shed, the other vital component is an atomic power-plant, I guess that illustrates the age of the book.

Parkinson shows how you can go into the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.

Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books.

A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is here.

In Denmark we call it "setting your fingerprint". It is about personal pride and prestige, it is about being able to point somewhere and say "There! I did that." It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement.

The point being, it's a constant challenge in software design to keep the bike shed discussions to a minimum.

And having a constant reminder of this dilemma is a good thing.

So what do we do about it?

Recently I've become a fan of simply not discussing the easy things. Responsibility for the programmatic "bike shed" complexity problems should briefly discussed via email. People are not forced to "attend" or participate in email threads, unlike mandatory staff meetings. Thus generally only those who care will provide input, and I find it is usually sound. Then I'll just hand the tasks off to someone with reasonable experience. What do you think?