The human mind loves to simplify concepts to more natural, understandable terms. That’s why bike sheds, shaved yaks, and airplane landing strips can teach us something about software development and project management.

Bikeshedding

Bikeshedding is the futile and disproportionate investment of time and energy arguing over marginal or insignificant details and requirements.
– Law of Triviality

The actual name of this principle is Parkinson’s law of triviality from 1957.

Bikeshedding comes from an anecdote of a nuclear power plant building committee.

Instead of focusing on the essential parts of building a technologically advanced facility like a nuclear power plant, they’ve spent their time discussing and planning the color of a small bike-shed on the premises.

Because this topic was an issue, they all could understand and find common ground in the most easily-understood aspects of the project.

Common ground

We are all guilty of this.

Either as the one pulling a discussion down to a more relatable level or being pulled down by another stakeholder.

It’s natural to want to be included in decision-making, so we need to be able to take part in any discussion. And too often, stakeholders think they’re forced to provide input.

The problem is that this leads to a discussion on a lower level of common ground, with output and decisions about insignificant things, and ignoring the more critical parts.

At this point, it’s more about the stakeholder justifying their attendance in the meeting, and the importance in the project, instead of having the best result as the first priority in mind.

It’s human, and we all can relate, but what can we do to not fall into this trap?

Agendas and priorities

One solution is meetings with a clear agenda and end time, with priorities and responsibilities clarified beforehand.

Another approach to satisfy a stakeholder when we already have the best design or solution for our problem is to give the decision-makers something actually to decide.

They participate in the project and make it better, thanks to their decision.

Stroking someone’s ego by fulfilling this human need of justifying your attendance and importance might seem silly. Still, it might lead to quicker decision-making without diluted compromises.

Yak-Shaving

Oh boy, did I shave many yaks in my life as a developer… and, most likely, so have you!

Yak-shaving is the process of doing many nested or dependent tasks to accomplish a goal.

Every sub-task seems to be necessary for its own respective context, but in regards to the actual initial goal, they are less and less linked and relevant.

The bad thing is that this is another natural way of doing things, and it happens all the time.

We end up with an unbound number of sub-tasks to complete our initial goal, and every sub-task will create new requirements with new sub-tasks, and your final goal is even further away than before.

For example, instead of adding a small text field to a specific front-end form, we must first find the best design pattern, and the best library to do so. Oh, we also need to update the package manager first.

And some of the other tooling can be replaced with something newer and better. But we also need to update the database connector.

And all this for adding a small field to frontend.

How to avoid shaving a yak?

Focus.

Software development is an incremental process. There’s no need to do it all at once.

Yes, maybe replacing that tool in your toolchain might be more difficult later on. But you wanted to add a small text field, not changing your toolchain, remember?

Try to see every task in the bigger picture. Will it really bring you closer to your goal? Or will it only create more requirements that weren’t there beforehand?

Cargo Cult

The term cargo cult was coined after World War II when anthropologists discovered that unusual rituals and religious devotion developed among tribal and more isolated societies on the islands in the South Pacific.

Even though the first documented case was the Tuka Movement in 1885 due to prior arrival of colonialists.

Their contact with the Europeans and Americans during the war made them associate the delivery of cargo and goods from the first-world counties as “spiritual gifts from the gods”.

To receive more “gifts”, they started to build airplane landing strips, planes made from twigs, control towers, and even military-style drills were imitated in the hope of pleasing a higher power and receiving more cargo.

Cargo cult programming

Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose.

It happens: We came back from a conference or meetup and learned about this new framework that everyone is talking about. And we immediately want to start using it for everything. Everything.

The same thing happens with software patterns. We finally got our head around a new design pattern, and suddenly it feels like it fits everything, so why not apply it everywhere?

• Not everything needs to be a singleton.
• A factory is not required for every object creation.
• React/Angular isn’t the best solution for every web project.
• NoSQL is not the holy grail for data storage.
• Kubernetes is not the answer.
• The list goes on forever…

We shouldn’t include any idiom we picked up on the way “just because”, without understanding its greater context and implications on our code.

But FAANG is doing it

Another prime example of cargo cult programming is the mindless inclusion of technology stacks just because the big 5 or any other successful company is using this particular stack.

No, we’re (most likely) not the size Google, and we don’t need to scale like it, especially when starting out.

Of course, we could start by using Kubernetes to orchestrate an armada of containers with multiple redundancy levels, sharded databases, geo-redundant data storage, Redis cache, Elastic Search, Apache Hadoop, and all the other great gizmos.

But this will not automagically lead to the same success. Only to a huge AWS/GCP/Azure bill and so much overhead to maintain that the actual product most likely will suffer from it.

How to choose

The proverb “Cobbler, stick to thy last” is good advice. Also, it’s terrible advice. We should always try to stick to what we know because we most likely achieve the best results with it.

If we ritualistically include code “just because”, we will have a big problem when it fails. Because we might not even really know why it worked in the first place.

But also, we shouldn’t restrict ourselves only to the things we know to be able to grow and become better software developers.

Remember that there is always more than one way to solve a problem. Learn from history, but not necessarily repeat it. Rituals won’t summon gifts from the heavens.

Conclusion

We are all guilty of everything I wrote about in this article. That’s not good, but it doesn’t have to be too bad, either.

Knowing about these terms and principles will help us to catch ourselves (mis-)using them and gives us the ability to change our behavior in certain situations.

By realizing when we fall into the trap of shaving too many yaks or building another bike shed in the backyard, we can free much time and energy, which is better spent on essential things.

Sometimes, I even enjoy a little bikeshedding or yak-shaving about mundane stuff, to let my mind wander. But I try to restrict it to private projects, and nothing of too much importance.

A good example is a book I’m working on. First, I wanted to write it in Markdown, then Asciidoc. Back to Markdown with another publishing framework. Right now, I’m using Asciidoc, again, after thinking about switching to Latex.

In the end, it doesn’t even matter which dialect I’m using or what toolchain builds the epub-files.

All this initial bikeshedding and the related yak-shaving of redoing, changing, and extending the toolchain took a lot of time from the one thing that actually mattered: writing the book.

Resources

• Law of Triviality (Wikipedia)
• Yak shaving (Wiktionary)
• Cargo cult (Wikipedia)
• 1959 Cargo cults in Melanesia (Scientific American)
• Cargo cult programming (Wikipedia)