Much ado about bike sheds, Part I

If you’re working in software, there’s good odds that you’ve run into the phrase “bike shedding” at least once. Maybe you were in a meeting or a group chat and sensed the discussion had wandered a bit. Then someone said something like “we should stop this bike shedding,” or, “who cares what color the bike shed is?”

Many of us learn what bike shedding means through context: it’s typically invoked as a red flag for a conversation that has lost focus, or a request to remain on topic.

Simple, right? Well… maybe, maybe not.

Bike shedding represents a pattern of perceived behavior that’s made its way into the tech industry as a term of art. Which is to say, we’re talking about a metaphor, a story, a myth, or a rhetorical flourish, one that’s often used by frustrated engineers to simultaneously complain about and shape the flow of a discussion. It seems like a healthy communication tool, until it isn’t.

In this series of posts, we’d like to drag everything out of the bike shed and examine the entire concept more closely. Whether you’re curious or cautious or skeptical (and we’re more than a little skeptical), we’re here to help. Later in this series, we’ll share some ideas for how to build healthier communication patterns with your team.

But first, we should talk a little history.

What is the bike shed?

Way back in 1957, history professor Cyril Northcote Parkinson published a book titled Parkinson’s Law: Or The Pursuit of Progress. The book expanded on an article that Parkinson previously wrote for The Economist, and contained an assortment of bureaucratic “laws”. Alongside the titular Parkinson’s Law (“work expands to fill the time available”) there was also Parkinson’s Law of Triviality:

…the time spent on any item of the agenda will be in inverse proportion to the sum involved.

To visualize this, Parkinson imagines a fictional finance committee meeting to discuss three proposals: they pass a $10 million dollar nuclear power plant proposal within a few minutes, then discuss a $2,350 bike shed at length, and finally spend the most time debating a $5 monthly coffee budget (this is all in 1957 dollars).

The whole book is a satire of bureacracy, which—well, more on that later in this series—but briefly, the point seems to be that meetings are bad and groups of people are foolish. The “law of triviality” comes off as a lightweight behavioral economics parable. Modern audiences might prefer something backed by research—books by Larry Hirschhorn, Dan Ariely or Daniel Kahneman are more in vogue these days—but Parkinson’s book was reasonably popular in its time.

But the version of the bike shed story that’s popular with software developers associates “bike shed” with color, not with dollars. For that, we jump forward a few years…

“Any colour will do”

On October 2nd in 1999, a software developer named Poul-Henning Kamp posts on a mailing list (for those who don’t know: mailing lists were where software developers went to get salty in the days before Twitter) to complain about the volume and distracted orientation of the mailing list, name-dropping Parkinson in the process.

The sleep(1) saga is the most blatant example of a bike shed discussion we have had ever in FreeBSD.

Kamp re-tells Parkinson’s story about the nuclear power plant and the bike shed (leaving aside the coffee), as though Parkinson’s committee were a true tale of bureacracy in action. Kamp’s point seems to be that reasonable contributions to the open source project were being held up by minutiae and possibly ego.

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.

Interestingly, Kamp also shifts the story’s central metaphor: the core idea is still here, but this is no longer an economist’s fable about topsy-turvy ratios of time-to-money, this is now about how critical attention is flowing to things that are not important.

I wish we could reduce the amount of noise in our lists and I wish we could let people build a bike shed every so often, and I don’t really care what colour they paint it.

Ultimately, this is incorporated into the project’s FAQ as:

Why should I care what color the bikeshed is?

The really, really short answer is that you should not. The somewhat longer answer 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 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. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.

So, since its humble beginnings in a 1957 book and a 1999 mailing list post, the “bike shed” concept has become so popular among engineers that it has entered our vocabulary as the term bike shedding. Variations on the entry above have appeared in other projects’ FAQs. There are blogs about the “bikeshed effect”. There are podcasts about it.

Why do software developers find so much resonance in the bike shed story? In our next post, we’ll take a closer look at the relationship between software developers and the bike shed.

Thank you to Kaleb Lape for collaborating on this post.