What is Cargo-cult programming?
Engineering culture
Cargo-cult programming is a style of software development in which people copy code, patterns, tools, or rituals because they look like what successful engineers do, not because they understand why they are needed. The result is software that has the form of good practice without the substance. It might compile, it might even appear tidy, but the extra code, ceremony, or architecture often solves no real problem and can make future change harder.
What this means
Most engineers learn by imitation at first. That is normal, and usually healthy. You look at a working example, copy the shape of it, then learn the reasoning as you go. Cargo-cult programming begins when the learning part never really arrives, but the copied habit stays.
That is why the term has a sting. It does not mean "someone used an example". It means someone kept the ritual after the reason had gone missing. A team adds a retry loop because "we always do that". A codebase carries ten lines of defensive boilerplate against a bug nobody can describe any more. A company adopts a fashionable architecture because an admired firm uses it, even though the local problem is nothing like theirs.
Why it matters
This term is worth understanding because it describes a failure mode that looks respectable from the outside. Cargo-cult code often arrives wearing the clothes of maturity. It has patterns, abstractions, comments, wrappers, and a serious expression. That makes it harder to challenge than obviously sloppy work.
It also matters because cargo culting does not stay confined to code snippets. Teams do it with process, architecture, hiring, testing, and planning. Stand-ups become theatre. Microservices become a badge. A build step survives because removing it feels risky, even though nobody can say what it protects. Once that habit sets in, organisations start spending energy preserving rituals instead of improving judgement.
How it works
Where the term came from
In hacker slang, cargo-cult programming became the label for code that copies the visible shape of a past fix without understanding the mechanism underneath. The imagery came into computing through Richard Feynman's famous warning about "cargo cult science", which described work that imitates the appearance of serious practice while missing the thing that makes it reliable. In software, the same idea fits uncomfortably well. The code has the look of craft, but not the tested reasoning.
There is an important wrinkle here. The wider phrase "cargo cult" has a colonial history and anthropology has become much more careful about it. Used lazily, it can sound smug or dismissive. So the safest use in engineering is narrow and precise. It should point to empty imitation, not to beginner learning, and not to people as if they are inherently foolish.
Why teams fall into it
Software is full of hidden causality. A database timeout, a framework quirk, a race condition, a browser bug, a security rule, a logging quirk, all can leave behind what looks like mysterious protective code. When somebody inherits that system, the easiest path is often to preserve the charm and move on.
Pressure makes this worse. If a release is blocked, people do not always have time for patient explanation. They copy the known good incantation, hope the tests pass, and promise themselves they will come back later. Later rarely arrives. The copied pattern becomes folklore. One engineer tells another, "never remove that line". The instruction survives even after the surrounding context has changed.
There is also a social element. Engineers are influenced by admired peers, successful companies, and elegant blog posts. If a respected team uses a pattern, the temptation is to import the pattern before understanding the conditions that made it useful. That is how sensible ideas become costumes. Dependency injection, event driven design, heavy observability, generated clients, strict typed wrappers, feature flags, all are valid in the right context. Any of them can become cargo cult when adopted as a reflex.
How it shows up in real work
The most obvious version is literal copy and paste. Someone borrows a code block from another service, a forum answer, or an AI assistant, trims it until the error goes away, and leaves the rest in place. There might be a lock that is never contended, a null check for an impossible state, or cleanup code for an object the runtime already cleans up. The system carries around a fossil from an earlier problem.
A subtler version appears in architecture. A team with a small product and modest traffic chooses a highly distributed design because they have heard that "serious systems" use queues, orchestration, sidecars, service meshes, and elaborate deployment choreography. Months later, they have mainly created more places for a simple change to get lost. The architecture is not wrong in the abstract. It is wrong for the moment.
The same pattern shows up in process. A company wants to become "more engineering led", so it introduces planning rituals, review gates, templates, and dashboards. Soon people are filling in forms that no decision depends on. This is cargo culting at organisational scale. The visible rituals of capability have been copied, but the underlying decision making has not improved.
One of the easiest tests is to ask a plain question: what problem is this line, layer, or ritual protecting us from, today? If the honest answer is "I am not sure, but it feels dangerous to remove", there may be a cargo-cult habit in the room. That does not mean the thing is useless. It means the team has lost the chain of reasoning and now depends on superstition.
Examples
A backend developer inherits a payment service. They notice every outbound API call is wrapped in three nested retries, a sleep, and an extra log statement. Nobody can explain which partner needed that behaviour or whether the partner still exists. New calls are copied from the same file, so the pattern spreads. The team is not designing reliability, it is photocopying it.
A front end team adopts an elaborate state-management library because "large products need one". Their app has a handful of screens and modest interaction. Six months later, simple UI changes require edits across actions, reducers, selectors, and middleware. The tool did not fail. The team imported the ceremony before they had the complexity that made the ceremony worthwhile.
A manager hears that high performing firms run architecture review boards, so one is created overnight. Engineers now prepare slides for routine library changes. The board rarely says no, but everybody learns to perform seriousness. This is cargo-cult programming's cousin, cargo-cult engineering culture.
Common misunderstandings
People often think cargo-cult programming just means "using examples". It does not. Copying a working example is one of the oldest and best ways to learn. The problem starts when the copied thing is kept without understanding or review.
It is also not just a junior engineer problem. Senior people cargo cult all the time, especially with architecture and process. Experience can make the ritual more polished, not less ritualistic.
Another mistake is to assume cargo culting means the copied thing never works. Sometimes it works by luck, or worked once for a reason that no longer applies. That is what makes it dangerous. Success can freeze bad understanding in place.
Finally, it is not the same as standardisation. Good teams share patterns on purpose. They document when to use them, when not to use them, and what trade-offs come with them. Standard practice is not cargo cult if the reasoning stays alive.
Risks and boundaries
The term can be misused as an all purpose insult. It is lazy to call every convention or every unfamiliar layer "cargo cult". Sometimes the current engineer simply does not know the story yet. Sometimes a strange looking guard rail exists because it prevented an ugly failure last winter. Respect the possibility that the awkward thing has a history.
There is also a cultural boundary. Because the phrase inherits a loaded metaphor, it is best used with care and precision, not as a joke about people who are learning. In a healthy team, the goal is to recover the why, delete what no longer earns its keep, and teach the reasoning forward. Sneering is not maintenance.
What to do next
If this pattern feels familiar, start making reasoning visible. Ask engineers to explain not only what a change does, but what risk it is meant to manage. A short note in code, a lightweight design record, or a clear comment about a known edge case can stop today's justified workaround becoming tomorrow's superstition.
Reward deletion as much as addition. The simplest way to test for cargo culting is often to remove one suspicious layer and see what breaks in a safe environment. Teams need permission to prune, not just permission to pile on.
It also helps to separate learning from production hardening. It is fine to begin with a copied example. It is not fine to ship copied mystery code without a deliberate review of what each moving part is for. Make "explain this in plain English" part of code review, especially when imports, framework wrappers, generated code, or AI written snippets appear.
FAQs
Is cargo-cult programming the same as copy-and-paste programming?
Not quite. Copy and paste is one common route into it, but cargo culting can also involve blindly copying architecture, process, naming schemes, or testing rituals.
Can cargo-cult code still work?
Yes, and that is why it survives. It may work accidentally, work for an outdated reason, or work while adding needless complexity.
Is using a framework cargo-cult programming?
No. Using a framework is normal engineering. Using one because it looks serious, while ignoring whether it fits the problem, is where cargo culting begins.
Does AI make this better or worse?
Both. AI can explain unfamiliar code, but it can also generate plausible boilerplate that teams accept too quickly. Fast copying raises the need for slower judgement.
How do you spot cargo culting in code review?
Ask what each extra layer protects against, whether that risk still exists, and what would happen if the code were removed in a test environment.
Is there a healthy opposite?
Yes. It is not inventing everything yourself. It is understanding enough to choose deliberately, then keeping the reason visible for the next person.
Sources
Cargo Cult Science (Caltech Library). The underlying idea of copying the form of a practice while missing the thing that makes it trustworthy.