A team of engineers are sitting in a conference room discussing a new service. They quickly decide on the API and storage. Availability zones and the number of replicas are also decided. The whole conversation takes no more than 10 minutes.
Then someone asks: “How should we name it?”
Half an hour later they are still arguing whether “Galactus” sounds grandiose enough.
This behavior is widely known as bikeshedding or with its more formal name - Parkinson’s Law of Triviality.
Discussing Trivial Things
Bikeshedding is the act of spending disproportionate amounts of time discussing trivial parts of a problem instead of focusing on more important topics.
Everyone who’s spent some time in the software engineering field has seen this behavior in one form or another. Serious decisions require in depth conversations and thorough discussions. But often we pick a minor or controversial detail of the topic and dive in it instead.
If a team falls victim to bikeshedding, they may spend massive amounts of time discussing small implementation details that may be of no impact to the system.
The story behind the term is that a board of directors met to discuss the construction of a power plant. Rather than discussing the complex decisions around the construction, they spent an hour talking about the color of the bike shed in front of it.
The Focus on Triviality
If everyone understands the importance of a particular discussion why do we focus on trivialities?
It’s about how familiar the participants are with the problem at hand. The more complex a topic is the harder it is to fully understand it. Complicated decisions require many changing factors to be taken into account which isn’t an easy task.
When we can’t fully grasp something we are less confident in expressing an opinion about it. The more trivial parts are easier to understand hence more people are comfortable discussing them.
The Grey Area of Bikeshedding
We’ve already outlined the cause of this behavior. In some situations a bit of bikeshedding is unavoidable and may actually be useful. It may help important details to surface that would be overlooked otherwise.
You may let your colleagues bikeshed freely on the URL format of a REST API endpoint after everything else is decided upon.
But most often this behavior is a sign of other problems such as bad leadership. Some topics are polarizing and people could have a hard time making a decision about them. We shouldn’t let the bikeshedding go freely with the expectation that a solution will come up naturally.
In such situations the leader should either move the discussion to a more productive topic or make a call. Being wrong about a minor decision is acceptable. Overlooking proper software design isn’t.
Should every controversial discussion be stopped then? Bikeshedding is considered unproductive because it focuses on trivial matters of little consequence. Not every debate that can’t be resolved instantly needs to be interrupted.
A Form of Procrastination
This behavior is a seductive form of procrastination as well. Since the team is actively discussing and pondering something it gives everyone the feeling that they are spending their time productively.
But this is a terrible trap to fall into. Those discussions take away valuable time that could be spent exploring architecture or understanding the business domain better.
We procrastinate on the hard calls or discussions. The hope is that once the low level details are clear, understanding the bigger picture would become easier. This is rarely the case.
Unfortunately, bikeshedding gives us a false sense of achievement deciding on trivial topics while the pressing ones remain.
Overengineering
In the software world, the Law of Triviality could also manifest as overengineering. There’s a fine line between planning and overthinking. Bikeshedding on trivial topics can leave us paralyzed and unable to make a decision.
When this happens we may decide to make the software more generic than it should be. We’d like to keep our options open in case we change our minds later. We put unnecessary abstractions and use complicated architectures so we can be saved if our decisions turn out to be wrong.
This is another way to postpone the actual decision. Also to make our job harder in the future. In reality a bad decision is often easier to handle than trying to avoid it like this.
No one knows how the product will change in the future. Most generic abstractions are left unchanged. So we are left with an overcomplicated project that we don’t have the time budget to simplify. The solution is the same - make a call.
Summary
- Bikeshedding or Parkinson’s Law of Triviality is the act of spending disproportionate amounts of time discussing trivial parts of a problem instead of focusing on more important topics.
- It occurs because people are more comfortable talking about things that they understand well rather than complicated multilayer problems
- It may be caused by bad leadership and their inability to make decisions
- This behavior can be considered as a form of procrastination in which we postpone making hard calls by endlessly discussing trivialities.
- In the software world bikeshedding often manifests as overengineering - implementing unnecessary abstractions and practices to keep our options open when we can’t decide on something.
