Bike-Shedding Effect: Why Small Changes Draw the Longest Debates

A group gives its time to the questions its members can answer, and almost everyone can answer a question about a shed. That is the whole mechanism. A proposal to rebuild the storage layer, change the pricing model or approve a reactor asks each person to admit the limits of what they know, and most people would rather stay quiet than reveal that; a proposal about a name, a color or a default setting asks nothing of the kind, so the hands go up. Kamp's email put it plainly: a power plant is so vast and complicated that people cannot grasp it and fall back on the assumption that somebody else checked the details, while anyone could build a bike shed over a weekend, so no matter how well prepared the proposal is, somebody will seize the chance to show that they are paying attention.

Kamp called the second motive setting your fingerprint, a Danish phrase for the wish to point somewhere and say that you did that. Weighing in on the trivial item is cheap, visible and safe: nobody will be blamed later for the shed, and the contribution is on the record. Weighing in on the reactor is expensive, slow and risky. The FreeBSD FAQ that preserved the term boiled the pattern down to one line that engineers have repeated since: the amount of noise generated by a change is inversely proportional to the complexity of the change.

The thread that set Kamp off had every feature of the pattern. Someone proposed that the sleep command accept a fraction of a second. The change was small, backward compatible and matched what two sister projects already did, and it still generated weeks of objections, counterproposals and amendments. The proposer held on and the change was committed, but the cost was paid by everyone who read the thread; Kamp's suggested warning for mail programs was that an email to several hundred thousand people consumes at least two man-weeks of reading before anyone decides whether it was worth sending.

Two limits belong here. The bike-shedding effect is an observation from practice, named by an engineer and illustrated by a satirist, and there is no body of controlled experiments measuring how much longer groups spend on trivial items than on weighty ones; the related laboratory work on how groups allocate attention does not use this label. And the shed is not always the wrong place to spend time: a naming decision that will be read a thousand times a day can matter more than it looks. The effect is the mismatch between the time spent and the stakes, not the triviality itself.

There is no study; there is an email. On Saturday 2 October 1999 Poul-Henning Kamp, one of the most prolific FreeBSD developers, sent a long message to the project's committers and hackers mailing lists with a subject line about a bike shed on greener grass, any color would do. He had not written it in anger; by his own account he needed a couple of days to calm down and a few more to see that his irritation at one thread was a reaction to a pattern he had watched repeat for years.

The thread was about whether sleep, a command that pauses a script for a number of seconds, should accept fractional seconds. Kamp wrote that it had pestered the lists for days, probably already a couple of weeks, and that the proposal was well thought out, gained compatibility with OpenBSD and NetBSD, and remained compatible with every script anyone had ever written. He called it the most blatant example of a bike shed discussion the project had ever had and bowed to the proposer for sticking with it through what he called carpet blanking from the peanut gallery.

Then he explained the phrase. C. Northcote Parkinson's Parkinson's Law and Other Studies in Administration, published in 1957, contains a chapter on what Parkinson called the law of triviality: the time a committee spends on an item is in inverse proportion to the sum involved. Parkinson's invented agenda has a finance committee of eleven wave through a 10,000,000 dollar atomic reactor in two and a half minutes, debate a 2,350 dollar bicycle shed for forty-five minutes, and spend an hour and a quarter on the committee's own refreshments, 4.75 dollars a month, before deferring that item to the next meeting. Kamp, writing from memory, placed the book in the early 1960s and repeated Parkinson's explanation of why: the plant is beyond anyone's grasp, the shed is within everyone's.

The email had, in Kamp's later words, far bigger impact than he expected. Within FreeBSD the bike shed became a yellow card, a word a developer could use to end a thread, and from there it traveled with FreeBSD committers into other projects, into the FreeBSD FAQ under the heading of why you should care what color the bikeshed is, and eventually into general use for any argument whose heat is out of proportion to its stakes.

The pattern appears wherever a group with mixed expertise meets about a mixed agenda.

The counters work by making the big item approachable and the small item cheap to settle.

• Name it. Kamp's term became a yellow card in FreeBSD because a single word can end a thread without insulting anyone. A team that agrees on the word in advance can call a bike shed when it sees one.
• Give the shed an owner. One person with the authority to decide the color, the name or the default, and the understanding that the decision is reversible, removes the item from the group's agenda altogether.
• Timebox trivial items and put them last. A ten-minute cap announced at the start, with the important items first, means the shed cannot eat the reactor's time.
• Make the big item discussable. The reactor gets two minutes because nobody can engage with it. Pre-reads, a short briefing from someone who understands it, and a list of the three decisions it actually involves give people something to say that is not a bluff.
• Ask the cost of being wrong. A question that takes thirty seconds and reorders most agendas: if this goes badly, what does it cost, and can it be undone?
• Settle style by rule. In software, a formatter and a style guide end the recurring arguments about brackets and names once, so reviews can spend their attention on logic.

The bike-shedding effect has a sibling and several neighbors that are easy to confuse with it.

• It is not a different phenomenon from the law of triviality; it is the same pattern named from the other end. The law of triviality is Parkinson's 1957 claim about committees and the arithmetic of his invented agenda; the bike-shedding effect is the phrase that came out of Kamp's 1999 email and the way it is used about projects, code reviews and online debates. Each page tells its own half of the story.
• It is not information bias, the appetite for more information that cannot change a decision. A group painting the shed is not gathering information; it is spending time where it feels competent.
• It is not the planning fallacy, the tendency to underestimate how long a piece of work will take. Bike-shedding describes how a group divides its attention between items, not how it forecasts the work on any one of them.