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 bureaucracy, 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…
Why do software developers find so much resonance in the bike shed story?
What’s important? What’s really important? How do you know it’s important? How do you know whether this thing is more or less important than that thing?
Parkinson mined a great deal of satire from what he saw as a kind of logical puzzle—looking at the costs, the committee, he suggests, ought to have spent more time on higher price-tag proposals as opposed to dwelling on relatively minor line items, like a bike shed or coffee budget.
So, is that the lesson we should take? That more expensive things are more important?
This framing doesn’t strike me as terribly realistic—regardless of its relative price, I might have valid reasons for being very not okay with a nuclear power plant going up in my backyard; in fact, if it were a bargain-basement nuclear reactor, my concerns would seem even more valid. But it’s hard to argue with cold, hard numbers, so using price as a proxy for importance can provide an attractive heuristic.
The modern version of this story, where caring about color is our benchmark for “trivial details”, is stranger still. Kamp’s mailing list wasn’t literally debating the choice of color, the whole color thing here was just a, ahem, colorful metaphor. For the metaphor to work, at all, we have to have a shared understanding of what’s important and what’s trivial. Kamp is saying (1) color does not matter, and (2) the topic they are debating matters as little as if they were debating color.
For decades, software developers have been fine with this. And yet… Color is an amazingly deep topic! There are books on the history of color. There are fascinating stories about how colors got their names, how they were made, how they impact fashion, how they tell stories… until software emits smells, color will be one of the most important aspects for developers to understand when considering how human beings will interact with our software.
An idea like “color doesn’t matter” should have been dismissed out of hand as ridiculous—a visual artist might spend months fine-tuning a combination of colors—and yet, software developers have generally been fine with this line of reasoning for decades.
This might just be weirdly myopic, if it weren’t a small part of a larger, more troubling pattern. Software developers—and other professionals who are oriented around quantitative thinking—have a tendency to dismiss more qualitative disciplines such as design, marketing, or management—which also turn out to be exactly the disciplines best-suited to mitigating the kinds of dead-end discussions the bike shed legend is supposedly built to address.
(Incidentally, in my experience, this is almost always a one-sided problem: I don’t see designers de-valuing mathematics or physics, I do see engineers and financiers regularly treating designers, marketing folk, and management with disdain, and the stories we tell about bike sheds are a part of that.)
One problem I have with the bike shed story is in how tempting it is to use the story to stop a discussion cold. “Nuclear power plants are important, talk about that, stop talking about bike sheds.”
In conference rooms and in online discussions, I have frequently seen software developers deploy the bike shed myth as an attempt to minimize a topic they see as unimportant and to label that discussion as a trivial distraction.
When someone says “oh, bikeshedding again”, or “who cares what color the bike shed is?” they are not only seeking to cut off discussion on whatever the topic at hand, they are also reinforcing a bias that frames entire categories of conversation as being of lesser value. Labeling a conversation a bike shed sends the message that we shouldn’t consider something that others have expressed interest in discussing. It is often used as a tool for signalling, “what I’m worried about really matters, not what they are worried about,” without coming right out and saying that.
One of the hardest parts of making software is the enormous complexity of this endeavor. Software developers regularly wrangle syntax, semantics, and semiotics, and the slightest misstep can bring the whole project crashing down around us. A stray semi-colon is not likely to ruin a novel, but will definitely crash your program. Spend enough time programming, or hanging around where programmers congregate, and you’ll encounter load-bearing comments, stylesheets which kill websites, and punctuation errors that crashed rockets.
If a stray punctuation can ruin your day, you are going to spend a lot of time sweating the small stuff. As developers, the fact that any of a million factors can lead us to catastrophic, trauma-inducing failure gives us a topsy-turvy and often arbitrary system by which to judge what’s important and what isn’t. We tend to have a lot of anxiety about things that might seem trivial in a different light, and the bike shed story is often our way of reassuring ourselves that (unlike other people) we’re worrying about the right things.
What’s missing from the bike shed?
What worries me most about this is: what if the bike shed story makes it harder for software developers to experience empathy?
Way back in Parkinson’s original story, an imaginary committee—an all-male team of scientists, engineers, and financiers—get together to discuss how to spend their money, then spend too much time talking about low-cost projects. Parkinson seems to just throw up his hands and admit a kind of defeat—let’s just label the problematic behavior and move on: bad meetings are inevitable… what can you do but laugh?
And yet, a well-organized, focused committee meeting isn’t impossible, any more than a rocket ship flying safely to the moon or a skyscraper withstanding an earthquake or a software project finishing on time. Humans do all sorts of hard things, all the time, by bringing skillful people together and empowering them to do their best work.
What if endless debates about what appear to be minutiae weren’t an unavoidable flaw of human psychology, but instead indicated a deficiency of expertise?
What if, all along, what if the “bike shed” is actually a story about how committees of scientists, engineers, and financiers are not truly well equipped to address the wide array of challenges that lie outside of their hard-won expertise? What if “caucus-style”—or “open floor”—meetings often preferred by STEM folk have a paradoxical tendency to further silence already marginalized voices?
What if someone in that meeting had said something like:
“Well, it looks like we’re past the time we’d originally allocated on our agenda for the bike shed discussion, and we’re no closer to a decision. Since it’s clearly a deeper topic than anticipated, I propose we spin off an exploratory project to evaluate bike shed options and present their findings at our next meeting. Can the project tolerate postponing a decision another month?”
Or:
“I’m noticing that no one from the design team is here today, so it’s not surprising to me that we’re having trouble deciding on a color. I’d propose we table the bike shed discussion until our next meeting, and I’ll be sure to ask our design lead if someone can join us then.”
Or even:
“Since I knew we’d be discussing the bike shed today, I conducted a survey of bike riders in our community, and spent a few days categorizing their responses into three broad categories…”
What does it look like when software developers sideline critical voices as “not important”? Remember when Google’s Photos app automatically tagged photos of black people as “gorillas” ? Or how it took Apple’s HealthKit five years to add menstruation tracking? Or how “smart home” devices keep being used by domestic abusers to further terrorize their victims?
Could discussions that included and amplified marginalized voices and perspectives have avoided these problems? I don’t know, but I’m pretty sure that these problems aren’t “trivial”. If it’s true that software developers generally know what’s important and worthy of consideration and what isn’t, then why do we see terrible-but-ultimately-avoidable outcomes as often as we do?
What if this is actually a story about blind spots?
What if a group of scientists, engineers, and financiers got together, and because they weren’t able to admit to themselves or others that they didn’t collectively know enough about design or color or how to structure a meeting in a way that facilitates productive discussion, they found themselves in an endless argument?
Bike sheds -> Our team’s blind spots
Assessing your communication
Communication is the lifeblood of every team. Ask these questions of yourself and maybe even open the floor to your team to help you examine your communication.
How do we feel?
When the salt begins to flow it should trigger your bike shed detector. Anxiety, stress, and fear might be warning you that people feel like they aren’t being heard. Too much negativity is a clear signal that your team is out of alignment.
How much time do we spend in meetings?
It’s normal for folks who like to get things done to balk at adding another meeting to the calendar. To an extent, this is probably a healthy pressure against wasting time. Unfortunately, your team may not be feeling enough healthy pain to push back because we humans tend to acclimate to our environment. This bike shed is one of the classics because most developers have no problem rallying around the cause of fewer meetings. I believe it’s still worth mentioning because the feeling of busyness so quickly lulls us into a false sense of security that we are getting things done.
What is the context?
It’s important to acknowledge when we are talking about the present context versus any other. Understand that team members may bear scars from similar situations. This isn’t a license to de-legitimize others’ experiences, because they may simply want to spare this team the pain they’ve experienced. Psychologists suggest that we may not be consciously aware of how our feelings affect our thinking. Identify and make explicit the contexts involved. This brings the bike shed into clear focus so your team can have a focused productive conversation.
Where do we disagree?
Everyone has a different perspective. By default most people only consider their own. You can identify this bike shed in the wild by noticing language differences. Often you will hear a repeated word or phrase. Write it down and continue listening. When you have a few repeated words and phrases from each point of view, you can compare. If you notice that one person is talking numbers and data and the other person speaks of feelings and style, you have just identified a potential disconnect. Maybe there are actually multiple conversations here, and everyone needs to get on the same page to understand whether there is even a difference of opinion at all. In keeping with the theme, perhaps one person sees only the size of the bike shed where another is more concerned with the curb appeal. The team should have both of these conversations with everyone making an effort to understand the distinctions between each topic.
Assessing your tribal assumptions
In his book, Peopleware, Tom DeMarco describes what he calls a jelled team.
A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts.
Sometimes a team is jelled to the point of perfection. Or at least that’s what it seems like from the inside. In reality, the team may have developed tribal assumptions and blind spots. It’s great to have a confident team, but we should always be on the lookout for things to improve. Don’t let a bike shed’s cloud of fear, uncertainty, and doubt slow down your team. Ask questions like these instead.
How easy is it to reverse course?
Fear of the unknown is a dangerous influence on your team’s behavior. I’ve seen pull requests stagnate because the team doesn’t feel comfortable shipping something when it feels risky and there isn’t a mitigation strategy. Consider embracing NoOps as a step toward reducing the pain of shipping.
Do we feel empowered to make decisions?
When developers take on a task, they are putting in the investment and so should be trusted to make the final call. If not trusted, then why are they on the team in the first place? Take note of the amount of chatter around seeking validation. Is there a hidden power structure? The team should also feel confident about using data to test their assumptions. Your team could have plenty of healthy discussion about which data to collect and how to use it, especially when you consider the alternatives. Some teams might not collect any data and become paralyzed with the fear of not knowing the impact of their changes. Others may collect lots of data and not know how to use it, or worse, not have much confidence that it is the right data.
Can we predict the impact to our business if we get this wrong?
When key stakeholders are unavailable, developers may be left without any sense of the strategic position of their code. This includes insights into your customer’s key features and most visible parts of your product. Stakeholders here run the gamut from customer support, marketing, executives, and data scientists. Everyone here has a lot of valuable information. Managers everywhere struggle to provide a healthy pipeline of relevant feedback for devs from the rich variety available in their organizations.
Do we understand the cost versus benefit to the business?
Maintaining a healthy flow of communication between all stakeholders is key if you want to avoid wasteful rework. Developers who understand the business needs can make better technical decisions. Helping strategic leadership understand technical constraints empowers them to plot a profitable course for the company. Everybody wins!
Does it work?
Sometimes we get so wrapped up in our opinions about quality that we forget to respect the autonomy of fellow developers. If the code works and passes all the agreed upon tests, does there really need to be an extended discussion about alternative approaches when the work is already done? You have an ideal bike shed in your mind. It’s probably an awesome bike shed, but remember that you weren’t the one who put in the work to build it.
Going deeper
Teams may have deep cultural dysfunctions. These will require lots of dedicated time and effort to fix. Everyone has human flaws, and your team is no exception. Some individuals will try to actively harm others. This is a sad reality. However, I believe in the vast majority of cases people would rather get along and do good work. Take time to reflect on the pain your team is experiencing. Discuss it openly and honestly. Then you will unleash your team’s ability to heal, emerging as better humans and coworkers than before.
The bike shed’s long and checkered history has a lot to teach us. Perhaps the greatest lesson is that we can push a metaphor way past the limit of usefulness. Though I may be guilty in this very post, I hope the illustration just makes the point more sticky. If we get too comfortable with the status quo, we will miss opportunities to grow. I hope identifying your bike sheds and encouraging healthy conversations around them improves the productivity and quality of life for your team.
