Bike-shedding, or the Law of Triviality
A city council is presented with the plans for a new nuclear power plant and needs to make some decisions on some details left open by the planners. These details can span from highly technical to very trivial, like the specifications for the nuclear reactor to the colour and material of the bikeshed for the workers
When meeting to discuss these details, they spend just a brief moment to approve the suggestions that are more technically advanced. Once they come to the bikeshed, they spend hours discussing everything from the material, colour, placement, number of bike stands, and so on. The more trivial the matter, the more time the council spent discussing it.
The story above was an argument presented in 1957 by Cyril Northcote Parkinson, a British historian. He claimed that members of an organization would spend a disproportionate amount of time on trivial matters. The time spent deciding on something in a group is inverse to the value, cost, or complexity of the topic.
The argument was named Parkinson's Law of Triviality and has since been used to describe how we tend to focus on the trivial matters where we feel more comfortable expressing an opinion. In software development, the term was first used in the BSD community to describe how members spent time discussing programming topics that were quite trivial.
The term "bike-shedding" became a metaphor, based on the original example described by Parkinson. There has been plenty of books and articles written on this topic, but this is a topic I believe it is time to revisit.
It's all about procrastination
In 2009, Jeff Atwood wrote about "the Bikeshed Effect" and defined it as a sort of procrastination. Atwood refers to studies done by psychologist showing that when people believe a task to be complicated, they are more likely to procrastinate. In software development, this occurs when we spend a lot of time working on reasonably simple topics instead of the more complicated ones. It turns out that bike-shedding is a natural way of avoiding hard work.
Somehow this never felt like a complete explanation to me. Most developers I meet don't like meetings, and they want to write code instead. They also like to work on more complicated features, while I frequently see simple bugs being left untouched for a long time.
While there is plenty of "bike-shedding", as defined by Atwood, happening in online forums, I see much less of it in workplaces. Could it be that we have eliminated the bikeshed effect in modern-day software engineering? I doubt we have, but how we work in software development these days the way "bike-shedding" happens has changed.
Programming as procrastination
One of the perks of being a freelance contractor is that you get to see a lot of different projects and experience a lot of different teams. You soon recognize several common patterns that fall somewhere between software anti-patterns and organizational deficiencies. The one thing I can say happens everywhere is what is sometimes known as the "Not invented here" effect. First time I heard about this was two decades ago when I was working at Ericsson.
Software engineers in this department (and probably elsewhere) were prone to writing code for things that had already been solved by the software community. In my project, we implemented our own ORM solution when there was already plenty of well-tested, open-source, ORM frameworks available. In hindsight, I've learned that this was because it feels safer to write code for something you feel familiar with and which, from your perspective, is relatively straightforward. You probably don't use that as an argument, but instead, claim that it is better writing the code in-house because the third-party alternatives have deficiencies that aren't acceptable or they don't exactly fit what you need.
The JavaScript community is full of such examples. There is the recurring joke about which of the latest frameworks that came out this week you should use for your project. Developers spend a disproportionate amount of time writing code for things that are solved already.
My own experience doing Android development has shown the same. When RxJava became the new hot topic in the Android community, we spent countless hours converting our existing codebase to use Observable instead of callbacks. In most cases, it had a minimal positive effect on the business value of the application, but we did produce a lot of new code, and we could now claim to have a reactive software architecture. I'm not claiming that a Reactive architecture isn't better than one that uses callbacks for everything asynchronous. Still, it will likely not be valuable to convert an existing, working solution unless you plan to rewrite the entire app.
Programming as a procrastination means writing code that carries little perceived risk but doesn't bring any business value to the product. It is still a form of bike-shedding, and we need to start recognizing this behaviour in our work.
Fewer meetings, more code
When Agile, Lean, SCRUM, and Kanban became popularized in software development, we reduced the number of meetings for developers (or at least we tried). Instead, we focused on producing code (or at least we tried). Meetings, where we discussed the software design, was replaced with pair- or mob-programming sessions. Code review meetings were chunked up in pieces and named pull-requests, and we got helpful online tools where we could do them without gathering in groups in a meeting room. The meetings we had to do were time-boxed (daily stand-ups, retrospectives, etc.) and we learned how to postpone decisions if we noticed that we couldn't decide upon them in those brief moments. These changes were all good, and we got to spend more time producing code, which is also good, I guess?
While we probably became more efficient in many ways, we also carried over the Law of Triviality to our new way of working. A software developers job is to write code that brings value to the product. Most product owners will value things that are unique to their product, so the developers need to solve challenges that aren't solved yet. Even if the feature you're implementing is something that was solved before, it is probably new for you. You are not an expert on this new feature unless you've built that once already (in which case it is probably not a priority for the product owner).
When you get asked to pick a new ticket for the next sprint, you will most likely pick something that you feel somewhat safe to do. If the feature requires a lot of research from the developer, it is likely they will postpone that task until they feel more comfortable with it. Avoiding new and seemingly complicated tasks is nothing strange or new for most of us. Still, it is the Law of Triviality happening in modern-day software development where we've learned to avoid long meetings where we only discuss trivial programming topics.
Non-trivial doesn't mean it isn't straightforward
Just because we don't feel safe implementing a specific feature doesn't imply it isn't straightforward. There are many reasons why the Law of Triviality would apply. A refactoring that would require a massive amount of simple but tedious work is not something most developers want to do. We don't get to play with the Cool New Thing or test the Latest Framework. Instead, we have to do plumbing in the Boring Legacy Code. We avoid it, not only because it will require a lot of work, but we can't be sure that it works afterwards because we need to work on code we weren't part of implementing in the first place. One developer's safe domain is another developer's unknown terrain.
You might be reading this and thinking "That's not right! I love writing code for things that I haven't worked on before!". That is true for most developers. We love a challenge, but to do them, we need to feel sure that we can do it or at least safe from what the results will be. Few people are willing to take significant risks with their job.
Hack Weeks to the Rescue!
It seems like the Law of Triviality is hard to avoid and that it carries considerable, perceived, risk. Developers will spend time writing production code only on where they feel comfortable. So how can we get them to step outside of their comfort zone and gain new skills and experiences?
Many tech companies these days arrange Hack Weeks, where everyone gets to play with whatever they want. The teams get to play startup inside their company for a week, with no requirement to produce anything of business value and thus not risk anything. Managers let the creativity of their staff run loose and hopefully pick up a few smart new ideas. Or to phrase it differently; "Why don't you all just play with whatever you want without thinking of the consequences?!"
In my experience, the outcome of these activities is rarely useful in production. Still, the developers gain new and valuable knowledge that lets them start a new task they otherwise might not have done.
I believe we can do this better and smarter. My tip to the developers participating in hack week projects is to pick a challenge that is related to specific business values, and not just a Cool New Thing. Stay focused on the product, and your hack week result is more likely to bring real and lasting value.
Recognizing procrastination
Bike-shedding is a natural behaviour regardless of your work. By recognizing that we all do it, we can learn how to reduce its effect on our work. By trying new things and allowing us to fail at those, we will become better developers.
If we can learn to identify when we start avoiding the more valuable work in our code, we can plan accordingly and let the team "play around" to learn new skills and evaluate different solutions. By understanding that procrastination is how we cope with uncomfortable or challenging tasks, we can also anticipate what this means for our work and deal with it better.
It is ok to procrastinate, but don't make a habit of it!