Cargo Cult: definition

This article was originally written in French for sfeir.dev. Original version can be found here

In an ever-moving world of software, it is sometimes hard to keep pace. Whether with the rise of AI today or the adoption of agility a few years back, we have had to evolve our practices and habits on multiple occasions. But have you ever had the feeling that these changes were perhaps not the right answer to your everyday obstacles? Were these changes — most likely imposed on you — justified, or were they the result of a futile attempt to replicate someone else’s success?

The origins of Cargo Cult

Cargo Cult is not a term native to the world of computing. It originates from a set of aboriginal rites in reaction to Western colonization. At the turn of the 20th century, Pacific civilizations found themselves confronted with the teachings of Christian missionaries, an abundance of material goods arriving by ship and later by plane, and with the lifestyles of Asians, Europeans, and Americans. All these elements, colliding with ancient indigenous mythological beliefs, led native peoples to imitate radio operators ordering supplies (delivered by cargo planes) and, more broadly, Western technology and culture, in the hope of producing the same effects. These behaviors gave rise to the movement, myth, religion, or term known as the Cargo Cult.

While this situation may raise a smile as we sit comfortably in front of our computers, we would do better to keep our egos in check — because we too are very frequently confronted with situations similar to Cargo Cult.

Cargo Cult in software

Beyond the history tied to the indigenous peoples of the Pacific, the definition of Cargo Cult can be simplified and applied to developers, engineers, or managers who reproduce technical or methodological practices without truly understanding how they work or why they are needed — much like how indigenous peoples hoped to receive supplies by building their own infrastructure without understanding the underlying mechanisms.

One example that, to me, reeks of Cargo Cult is agility. It is a topic that still sparks debate today, with all the absurdities that can be associated with it. The Agile Manifesto and its values gave rise to a variety of practices, but if we seek to benefit from them simply by mimicry (e.g., “they succeed using sticky notes, so I’ll use sticky notes”), we quickly end up with more problems than solutions. The excesses of agility also led, in turn, to the emergence of Software Craftsmanship, whose practices have unfortunately also been subject to the effects of Cargo Cult for several years now.

Another example that also stirred debate for many years (and still does?) is the use of Kubernetes, and more broadly all the supplementary tools we feel compelled to install on our cluster to be “production-ready” in the eyes of the industry. Do we actually need them? Is there not a faster and cheaper solution for our needs? These are questions that deserve careful thought before diving headfirst into an ocean of otherwise avoidable problems.

Today, a technology that is likely already experiencing the effects of Cargo Cult is AI. Now present everywhere, for everything and nothing, one can easily wonder whether the choice to use it is always well thought-out.

How to avoid it?

Cargo Cult is the blind imitation of a practice without a deep understanding of how it works. Does that mean we need to be an expert? Not necessarily. Every context is different and will not necessarily be conducive to implementing any given practice, no matter how widely recommended it may be.

Another term closely related to Cargo Cult, and one I find particularly amusing, is Hype Driven Development — a spin on practices like Test Driven Development or Behavior Driven Development. Unlike Cargo Cult, which has a broader meaning, this refers to choices driven primarily by trend or fashion, sometimes knowingly, while yielding to social or marketing pressure. I think the adoption of the various frontend frameworks (React, Vue, Angular, Svelte, …) over the years is a good example. While they have brought a great deal of value to the ecosystem, some projects suffered from a forced transition or adoption driven by the “hype.”

Conclusion

To summarize: take a step back from your choices and practices, and act with discernment. There is no need to follow the lead train closely and run on the same tracks to produce quality software and infrastructure. Draw inspiration from successful practices and adapt them to your own context to get the most out of them.