What exactly is bikeshedding?
A recent conversation brought a renewed vigor to my use of the term “bikeshedding.”
The term was coined c. 1957 by C. Northcote Parkinson to illuminate a discovery he made – that groups of people tended to make a futile investment of time and energy on disputes over minor, marginal issues while more serious ones were being overlooked.
Parkinson observed the dynamics of a committee whose job was to approve plans for a nuclear power plant. The committee spent the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bike shed roof while neglecting the design of the power plant itself. The latter being far more important but also far more difficult to criticize or even discuss constructively. Parkinson understood that this was because the power plant was so vast, so expensive and so complicated that people simply chose not to try to comprehend it, and instead they fell back on the assumption that somebody else checked all the details before things got to them. His observations were formalized into Parkinson’s Law of Triviality:
- The time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved. (Not to be confused with his other law which states that “work expands so as to fill the time available for its completion”.)
What color is your shed?
“Bikeshedding” as a notable phenomenon of software development in groups was later popularized in the ’90’s by the Berkeley Software Distribution community. Poul-Henning Kamp used bikeshedding as a metaphor indicating that one need not argue about every little thing just because one knows enough to do so. It was Kamp who introduced the reference of “what color to paint the shed” via a rather lengthy and well-distributed email rant.
Just say “No…”
While it can be fun to discuss what color the shed should be (everyone has an opinion…) bikeshedding is, in fact, a form of procrastination. Our job as software developers is to deliver features and solve business problems, not to generate never-ending discussion. As Marc Andreessen wrote, “we will be judged by what we – and our code – have done, not the meta-discussion that went on around it.”
So the next time you feel yourself getting drawn into a protracted “what color should it be” discussion, consider pulling out the yellow card, and see if you can ship something instead…
Related principles:
- Wadler’s law: The bulk of discussion on programming design centers around syntax (which, for purposes of the argument is considered a solved problem), as opposed to semantics.
- Sayre’s law: In any dispute, the intensity of feeling is inversely proportional to the value of the issues at stake.
