Bikeshedding
Recently at work, I got the chance to give a presentation on any topic of my choice. As tempting as it was to stay within my comfort zone and come up with something technical or directly related to my role, I decided to pick something outside of my wheelhouse yet relevant to my job, team and nearly anyone who works with other people. That topic was: Bikeshedding. The following are excerpts from the script I prepared to accompany my slides.
The origin
The concept of bikeshedding was debuted in an Economist article by C. Northcote Parkinson in 1955 where he introduced “Parkinson’s Law”. I won’t go into too much detail on what “Parkinson’s Law” is, but you can think of it as like 1950’s Dilbert with commentary on bureaucracy.
One of the concepts he introduced in Parkinson’s Law was the Law of Triviality. It stated,
...the time spent on any item of the agenda will be inverse proportion to the sum involved.
I know that’s kind of a weird way to structure a sentence, but the concept he was trying to convey was:
When we work with other people on projects, especially when it comes to meetings, we will often find ourselves focusing on the little things that don’t matter as much. This is counterintuitive because what we should be doing is dedicating more time to the things that cost more money, require more effort and are more complex.
This is probably a scenario I think most of us can relate to. We are on meetings or projects where people would get hung up on some small detail that doesn’t really affect what you are all there to solve. This typically results in everyone coming out of the meeting thinking it was a waste of time – and it probably was! What you experience in those situations is an example of Parkinson’s Law of Triviality aka bikeshedding.
But that still doesn’t really explain where the term “bikeshedding” comes from. Well, bikeshedding comes from Parkinson’s imagination – that’s pretty much it. He needed an example to illustrate his Law of Triviality. And what could be more timeless than a nuclear power plant and a bike shed?
The bikeshed
Imagine a scenario where there’s a project to build a nuclear reactor power plant. Part of the plan involves a shed for employees to store their bicycles in while they’re working at the nuclear reactor facility. Doesn’t beat slushy machines, Ping-Pong tables and pizza parties but it’s still a nice office perk, right?
During the project meeting with management and all the involved teams, the topic of the bike shed is brought up. Lots of people have opinions on the bike shed, including where it should be located, how many bikes should it hold, what kinds of locks to use, what material to build it out of, and MOST importantly, what color it should be painted. The discussion goes on for what seems like an eternity.
Within the remaining 15 minutes of the meeting, an engineer goes over the proposal for the nuclear reactor itself, detailing some of the systems used, safety features, expected power output, etc. Maybe the engineer needed some input from other people in the meeting to make certain decisions. Maybe those decisions were holding up the project. It might be hard to get any meaningful discussion going or to receive the input necessary to make a decision in the short amount of time remaining.
To recap, in this hypothetical situation, the project’s goal was to build a power plant to generate power. That’s the mission objective for everyone involved. However, the most amount of discussion and time was spent on the thing that not only cost the least amount of money but was relatively insignificant to the entire project’s goal. The bike shed’s existence does not really make a difference in the power plant’s ability to generate power, however it managed to derail the entire meeting and hinder progress on the power plant.
The why
Recognizing that this does happen hardly does us any good if we don’t understand why it happens. The explanation, like the reason for most of our problems, is human psychology. Whether we can admit it or not, we all desire ways to prove our worth, contribute to discussions, and receive validation for the work we’ve done. It’s just one of quirks with human nature and how our brains are wired that causes us to have such biases.
A power plant is extremely complicated, expensive and requires specialized knowledge to build and operate. On the inverse, a bike shed is simple, cheap, and just about anyone could build it.
If you get a group of people in a room to discuss both a power plant and a bike shed, people will come in with the full understanding of what a bikeshed involves and therefore will have more to say about it. On the other hand, nobody is going to understand everything about a power plant inside and out. It’s too complex and there’s too many moving pieces. This can cause hesitation in discussion. After all nobody wants to embarrass themselves.
From the outside, we could assume anyone who is working on building the nuclear reactors must understand it fully and therefore we don’t need to worry as much about it.
We’re comfortable talking about something as simple as a bikeshed. Without even realizing it, we have a desire to “argue” (I use the word “argue” loosely) we have the desire to argue and inject our input into the bikeshed to make sure we’ve made our contribution. After all, once a bikeshed is built you can point to the color of it and proudly say, “I did this!”.
Yes, this creates a lot of time and money wasted. But please don’t take your frustration out on the poor bikeshed. It’s just an inanimate object. In fact, we need bikesheds. They’re objectively good things to have, they’re just not as important as other things. Don’t hate the bikeshed, hate the bikeshedder.
As written by Poul-Henning Kamp on the FreeBSD mailing list almost 25 years ago…
“...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.”
Dealing with bikeshedding
Learn to recognize bikeshedding when it happens.
Ask yourself, “should we be dedicating so many resources to the problem at hand as we currently are?”
- If you say “yes”, then you should be good to keep moving forward.
- If you say "no", you’re probably in a bikeshedding situation.
How can you correct bikeshedding when you recognize it?
There’s not always a simple answer. The truth is, sometimes it would cost even more time and energy to correct bikeshedding than it’s worth. Even though an initiative might be getting bikeshed, it might cost you less in time and resources overall to just let it play out and come to a natural conclusion without interference.
How do you avoid bikeshedding before it happens?
- First, recognize your own tendencies to bikeshed. This isn’t intended to make you feel uncomfortable about sharing your opinions in a meeting or afraid to speak up, but more putting yourself in check on which things are worth debating and what things should you just learn to let go.
- When developing a project plan or a meeting invite, try to anticipate where bikeshedding could occur. This anticipation could be built off what you know about the project and the people involved and what past experiences you’ve had with both. If you know certain things need to be accomplished within a certain amount of time, make sure you’ve got a good structure and agenda established before the meeting.
- Another easy way to avoid it is to only meet on the things that need discussion. If a trivial decision can be made via a simple vote or chat message, don’t have a meeting about it.
Is bikeshedding a universal truth?
No, it is not. It’s just an observation that was made over 70 years ago. There’s some research and studies that back it up, it is a real thing, but it’s not something that is true in every scenario. Sometimes we do dedicate the appropriate amount of time and energy into the things that matter. In a way, it’s almost a self-defeating prophecy in that the more we recognize that bikeshedding exists, ideally the better we become at preventing it, and hopefully the less true the law of triviality becomes over time.
Applying these concepts in my role
Don’t let perfect get in the way of good
In security and technology, we often fall into the trap of only accepting 100% completion of a goal, whether it’s attainable or not. Instead, we should approach everything we do with a risk mindset. Sometimes 75% completion reduces 90% of the risk – depending on the situation, some may find that acceptable.
For example, if we’re implement a new security control but we can only apply it to Windows and not Mac, why should we let the opportunity to better secure our Windows machines to go waste because we can’t do the same thing on the Mac. If we can only enhance the security of one department but not the other, why would we not go ahead and better secure one department. That’s not saying we never revisit the solution for Macs or the solution for the other departments, but it is saying let’s not give up on meaningful change because someone says it must be done perfectly in every aspect.
This can certainly cause problems in the other direction, of course, where technical debt and fracturing of solutions creep in. That’s why it’s important in everything we do to keep balance and focused on what we’re all working to solve at the end of the day.
Don't let bikesheds give you a false sense of security
Bikeshedding doesn’t just appear when you’re building something, it can also creep up when you’re trying to fix something. In the heat of a scenario like incident response, just because you closed a gap doesn’t mean that’s where your job ends. Just because another team tells you something has been fixed, or just because a team tells you something isn’t an issue, doesn’t mean that’s always correct. You should trust that they believe they’re telling you the truth, but it's your responsibility to verify.
Approach serious issues with the understanding that controls can fail and that misconfigurations do occur. Be thorough when dealing with incidents, vulnerabilities, patches, and risk. Don’t let your focus on bikesheds give you a false sense of security.
And, don’t be afraid to call it out when you see it in order to keep everyone on task.
Let others paint it purple when you wanted it green
You can’t control other people, you can only control your own thoughts, emotions, and actions. Sometimes the best thing for you, the other person, and the project at hand is to just concede and let others have their way.
If someone else feels strongly about something you disagree with, ask yourself “Is this actually important” or “does this actually impact our goal” If the answer is anything less than “yes”, you should try to re-think how much your position is actually worth fighting for. There are certain things we should be fighting for all the time and every time, but not everything falls into that category.
Be respectful of your own time
Just like we shouldn’t waste each other’s time on trivial things, I have been trying to not waste my own time on trivial things. Obviously if there’s a task you do repeatedly, it makes sense to spend time automating it to save time in the long run. It’s also valid to take your time scripting something less important if you’re using it as a learning exercise. But more than once, I’ve scripted something that only needed to be done once, but the time it took me to write the script exceeded the time it would of taken me to just do the thing manually.
Bikesheds are OK
And finally, bikesheds are OK and can be useful. They do have their place. Just because something looks like a bikeshed doesn’t mean we should disregard it completely and never address it. It just means we recognize it for what it is, and that we spend the appropriate amount of time and resources on it.
Closing
I realize this phenomenon is probably not a new concept to most of you, but I do think there’s value in talking about it and having a commonly understood label for it. I hope if nothing else this post might encourage you to read more on the subject. If you do want to read more, these are the two main resources I used to put this together.
The first is an excerpt from a 1999 FreeBSD mailing list. The author was so frustrated with the amount of bikeshedding being done within the discussion that an entire website was dedicated to it.
The second link deals more with the psychological aspects and provides a lot of great examples to help illustrate this problem in more detail. So, if I was unable to articulate things well enough, I encourage you to check out that second link to help fill any gaps.
Thanks for reading.