||This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (February 2012)|
Parkinson's law of triviality, also known as bikeshedding, bike-shed effect, or the bicycle-shed example, is C. Northcote Parkinson's 1957 argument that organizations give disproportionate weight to trivial issues. Parkinson observed and illustrated that a committee whose job is to approve plans for a nuclear power plant spent the majority of its time with pointless discussions on relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the less-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticize constructively.
The law has been applied to software development and other activities, and the term "bikeshedding" was coined as a metaphor to illuminate Parkinson’s Law of Triviality and was popularized in the Berkeley Software Distribution community by Poul-Henning Kamp and has spread from there to the software industry at large.
The concept was first presented as a corollary of his broader "Parkinson's law" spoof of management. He dramatizes this "law of triviality" with the example of a committee's deliberations on an atomic reactor, contrasting it to deliberations on a bicycle shed. As he put it: "The time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved." A reactor is used because it is so vastly expensive and complicated that an average person cannot understand it, so one assumes that those that work on it understand it. On the other hand, everyone can visualize a cheap, simple bicycle shed, so planning one can result in endless discussions because everyone involved wants to add a touch and show personal contribution.
Problems exist when you suggest building something new for your community, like a bike-shed, and then everybody begins argue about its color, and in the end no bike-shed will even be built. The point when someone brings up bikeshedding is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the materials that will be used or the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so, as it better to first just build bike-shed, something trivial like the color can easily be talked about or changed later. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.
Thus bikeshedding involves discussions about relatively unimportant issues which result in extensive debate. It may be the result of individuals who wish to contribute feeling that they do not have the knowledge or expertise to contribute on more significant issues. Bikeshedding can result in discussions that, whilst on-topic, nevertheless effectively drown out other discussions on more significant issues. On the other hand, it also suggests that community leaders might need to consider how they can better assist and/or support those with less knowledge and expertise to contribute to the community in possibly more productive ways.
Although discussion can meander in any topic, the probability of meandering goes up as the technical difficulty of the topic goes down. After all, the greater the technical difficulty, the fewer participants can really follow what's going on. Those who can are likely to be the most experienced developers, who have already taken part in such discussions thousands of times before, and know what sort of behavior is likely to lead to a consensus everyone can live with.
Thus, consensus is hardest to achieve in technical questions that are simple to understand and easy to have an opinion about, and in "soft" topics such as organization, publicity, funding, etc. People can participate in those arguments forever, because there are no qualifications necessary for doing so, no clear ways to decide (even afterward) if a decision was right or wrong, and because simply out-waiting other discussants is sometimes a successful tactic.
The principle that the amount of discussion is inversely proportional to the complexity of the topic has been around for a long time, and is known informally as the Bikeshed Effect. This causes decision paralysis. What many people do not realize is that the bike-shed effect is, in fact, also a form of procrastination. And it can suck in highly technical developers, along with everyone else.
To many, diagnosis is the first step towards treatment. Simply by identifying a discussion as a "bike-shed", much of the energy that has been spent in the discussion can be dissipated. Problems arise when there is not agreement over whether something is a major consideration or a minor detail.
In the third chapter, "High Finance, or the Point of Vanishing Interest", Parkinson writes about a finance committee meeting with a three-item agenda.
The first is the signing of a £10 million contract to build a reactor, the second a proposal to build a £350 bicycle shed for the clerical staff, and the third proposes £21 a year to supply refreshments for the Joint Welfare Committee.
The £10 million number is too big and too technical, and it passes in two and a half minutes.
The bicycle shed is a subject understood by the board, and the amount within their life experience, so committee member Mr. Softleigh says that an aluminium roof is too expensive and they should use asbestos. Mr. Holdfast wants galvanized iron. Mr. Daring questions the need for the shed at all. Mr. Holdfast disagrees.
Parkinson then writes: "The debate is fairly launched. A sum of £350 is well within everybody's comprehension. Everyone can visualize a bicycle shed. Discussion goes on, therefore, for forty-five minutes, with the possible result of saving some £50. Members at length sit back with a feeling of accomplishment."
Parkinson then described the third agenda item, writing: "There may be members of the committee who might fail to distinguish between asbestos and galvanized iron, but every man there knows about coffee – what it is, how it should be made, where it should be bought – and whether indeed it should be bought at all. This item on the agenda will occupy the members for an hour and a quarter, and they will end by asking the Secretary to procure further information, leaving the matter to be decided at the next meeting."
There are several other principles, well known in specific problem domains, which express a similar sentiment.
Another, applied, example is the duck technique in corporate programming: a programmer expects their corporate office to insist on a change to something (anything at all) on every presentation to show that they're participating, so a programmer adds an element they expect corporate to remove on purpose. Quoted from Jeff Atwood's blog, Coding Horror:
This started as a piece of corporate lore at Interplay Entertainment. It was well known that producers (a game industry position roughly equivalent to project manager) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn't, they weren't adding value.
The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen's animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation.
Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "That looks great. Just one thing: get rid of the duck."
The law has been misquoted as the "colour of the bike shed" effect, although in Parkinson's discussion the issue related to the construction of the bicycle shed, with no reference to its colour.