Following are some thoughts I recently had about cargo cult and Brandolini’s Law in software development.
Brandolini’s Law says that the energy required to fight misinformation (or “bullshit”) is way higher than the energy required for spreading the misinformation in the first place.
Cargo cult is the phenomenon where people try to copy what they see others doing and hope to get the same results, without understanding the context or the causality that leads to those results, or even without doing that same thing at all but something that just looks similar on the surface.
Since misinformation and misconceptions in software development are often a simplified, dumbed-down version of the real concept, they make for click-baity social media content and find lots of agreement from people feeling validated in their ways of working or in their misguided understanding of a practice or concept. It spreads faster, wider, and with less effort than the attempts of a few trying to educate and inform with much more detailed and nuanced content or discussions. Because the information is always behind the misinformation in terms of the size of its audience and the rate of spreading, I think we need more of the following:
- People who learn that they were wrong when they unintentionally spread misconceptions (e. g., on social media, YouTube tutorials, etc.) and then not only admit it (which in itself would already be quite honorable) but who then try to address their same audience and attempt to revert the damage: Informing them what they learned since but also about how misconceptions spread and asking them to also spread the corrections. What a great world would it be if corrections would go viral as well?
- Professionals being more aware of the problem of cargo cult and thus being more critical when they hear simplistic “facts.” Not resistant to advice but curious, asking why and maybe even looking into the history and original sources of a concept or practice.
Some examples of where I followed this advice myself and keep doing so
Spreading GitFlow
After I learned about GitFlow in one of my first jobs early in my career, I thought it’s the pinnacle of software engineering. It felt so beautifully complicated and “professional.” I proudly taught it to some friends who were still in university or also early in their careers. A few years later I learned about the problems with GitFlow and similar branching models and about the fact that even its creator had advised against it for a few years already in a very visible warning in his very same blog post that originally spreaded it. I also learned about socio-technical practices, systems thinking, CI/CD, and DevOps. So I asked my friends who I taught about GitFlow a few years earlier whether I could show them how I was wrong and what I would do differently now and why. I showed them different alternatives to GitFlow, including continuous integration/trunk-based development and simpler feature branching models, and we discussed what made sense depending on context (including possible transition paths depending on where they were). It’s not that I had simply learned a better way, or that the industry had advanced; I had spreaded practices that I was told were a “best practice” despite the information to the contrary already being widely available, if only I had bothered to look a bit deeper. I’ve since become much more nuanced and careful with what I teach and spread (see below). More importantly, I’ve become much less prone to hype or to seeing things as “professional” just because they are complicated or because I only have a surface level understanding of the consequences and how it affects the system as a whole.
Addressing misconceptions early when teaching
When I teach technical practices, software design techniques, etc., nowadays I explicitly mention common misconceptions, myths, and pitfalls early on. That way I try to prevent what a developer has heard about a practice or concept from setting them off on the wrong path from the start. It also reassures them that I haven’t just heard about it from another developer or in a single team, or read/heard about it in a random blog article or YouTube video. I explain the why behind it, and I raise their awareness for misconceptions they may commonly come across and why (not just that) those are wrong. I encourage them to spread the why and to spread the corrections of common myths. Still, so far Brandolini’s Law wins. It’s not rare that groups/teams of developers as a whole hear about a concept for the first time even when it would seem basic to me and others, or that the majority of a team or organization is convinced that some misconception is true even when corrections of it are already abundant. We still have a long way to go as an industry and as a profession.
Raimund Krämer 