Everybody was cargo culting
My personal experience to jump off the bandwagon (effect)
Imagine the following situation. One of your experienced colleagues talks about doing some work, which she’s passionate about and sure it will provide better results for the team. She has fire in her eyes when she talks about replacing technology X with Y.
You feel it right into your heart. Your colleagues seem to agree with her. She’s so right. Though, she hasn’t proven the business value of her idea (just the technical aspects of it). You are tempted to agree too. That moment, I was there many times.
That’s the bandwagon effect when you align your opinion with the majority’s opinion, or what you perceive as the majority. It’s similar to the cargo cult: software engineering, following blindly what the others do.
The latter was coined by Steve McConnell, Code Complete’s author:
Cargo cult software engineers justify their practices by saying, “We’ve always done it this way in the past,” or “our company standards require us to do it this way” — even when those ways make no sense. They refuse to acknowledge the tradeoffs involved in either process-oriented or commitment-oriented development.
Cargo cult (science) was termed by Richard Feynman, who was inspired by the WWII stories of the South Seas people. They’ve built a runaway, a control tower, and even an airplane from bamboo sticks, in the hope the god-like airplanes will arrive again and drop the marvelous cargo. They did everything by the book, but it didn’t work — something essential was missing.
Back to my experience — I’ve identified a cargo cult moment, but what’s now, how to deal with it? What should you do next time? In the following lines, I’ll try to illustrate my actions as I learned in time.
Value
Among our responsibilities as developers, we’ve been hired to help the business making the right decisions. The software we develop brings value. Using any of the currently hyped frameworks, just to say you are using the cutting edge, attractive, everybody speaks about, doesn’t mean a thing if it doesn’t bring value. As simple as that.
So, what to do? Don’t take things for granted; question the suggested idea:
- What is it going to solve? Why will it make us more productive?
- How will it bring new customers?
- Will it scale?
- Do the benefits outweigh the cost?
- Do we need specific training?
If you can’t get the answers from her, find the person who can. Either, other developers, project managers, or any stakeholder you may find relevant, just don’t keep them unanswered. Leave no stone unturned in the search for knowledge.
Furthermore, it is highly suggested to allow enough time to prototype the idea to get more insights, and some of the questions answered.
Anyhow, I bet you can find more questions; please do share in the comments section.
Don’t get confused by the experience
Titles and positions won’t make everything your colleagues say true. Sure, they might have more experience, more knowledge — but, remember, everybody makes mistakes. Sometimes, as an outsider to a problem, you are free of misconceptions and assumptions, which helps you see the details clearly and in a different way.
Don’t weigh down the solution based on the person proposing it; otherwise, it creates a bias — so separate between the two. Consider the pros and cons of the idea, share it with them — it is in your responsibility. They expect it from you.
Don’t be afraid to be proven wrong, defend your idea, and treasure the moment, you can learn from any experience. So be positive about it.
Final words
Cult culture can destroy any software projects. Thus, being aware of the bias created by it gives you an edge to avoid its effect.
Be proactive. When identified, reduce the impact by allowing yourself enough time to search for more information, set (alone) focus time to reduce unreasonable judgment influence, play devil’s advocate for important decisions, and make sure to ask many questions.
