Cargo Cult Software Engineering

Last year a mentor of mine recommended I read Richard Feynman's 1974 commencement address at Caltech, the one about what he called "cargo cult science". It changed how I think about work.

During the Second World War, Pacific islanders had watched military planes land on improvised airstrips, delivering cargo: food, equipment, supplies. After the war ended the planes stopped coming, and some islanders built replica runways out of bamboo, lit signal fires, and carved wooden headphones to wear while sitting in control towers they'd built from straw. They'd replicated the form perfectly and no planes came.

Feynman's point wasn't about the islanders. It was about scientists who follow the rituals of scientific inquiry, the conferences and the papers and the methodology sections, without the intellectual honesty that makes science actually work. They do everything that looks right, and the planes still don't land.

I think about this regularly in software engineering.

The Rituals We Perform

Watch a typical software team and you'll see rituals everywhere. Daily standups where everyone recites what they did yesterday without anyone actually listening. Sprint retrospectives that produce "fugazi" action items nobody follows up on. Code reviews that check formatting but not logic. Architecture decision records that get written after the decision is already made. Story points that get reported up to management as if they were units of measurement.

Each of these practices exists because someone, somewhere, did it for a real reason and it worked. Standups originated in teams that genuinely needed to coordinate across dependencies every morning. Retrospectives were invented by teams that took continuous improvement seriously. Code reviews catch real bugs, when the reviewer actually reads the code. Adopt any of them without understanding the reason underneath and what you get is the bamboo runway: the ritual, and none of the result.

Why This Happens

The pattern is predictable. A successful company publishes a blog post about how they work. This is how Spotify organises engineering teams. This is how Google does code review. This is how Netflix handles deployments. The industry reads it and copies the form: the squad model, the review checklist, the deployment pipeline.

What they don't copy is the context. Spotify's squad model emerged from specific scaling challenges with specific people and specific technical constraints. Google's code review culture is embedded in decades of institutional knowledge and tooling. Netflix's deployment confidence comes from years of investment in chaos engineering and observability.

Lift a practice out of one context and drop it into another without understanding why it works and you have the cargo cult problem exactly. You've built the runway, and the planes aren't coming, because the planes were never about the runway. They were about the logistics network and the supply chain and the war effort behind them.

What It Looks Like in Practice

I see this most clearly with Agile. The Agile Manifesto was written by people who valued individuals and interactions over processes and tools. Twenty years later, "being Agile" mostly means buying Jira licences and having a certified Scrum Master run your ceremonies. The form is immaculate. What goes missing is the substance, which was always the willingness to adapt, to communicate honestly, and to deliver working software frequently because you care about the outcome.

Microservices are the other obvious example. Amazon and Netflix decomposed their monoliths into services because they had specific scaling and organisational problems that monoliths couldn't solve, and they did it gradually, painfully, over years. The industry cargo-culted the result instead: successful companies use microservices, therefore we should use microservices. Teams of five people split their simple CRUD application into twelve services, added a message broker, a service mesh and distributed tracing, then spent the next year debugging network issues that didn't exist when it was one application.

The same thing happens with infrastructure as code, with test-driven development, with domain-driven design, with every practice that has a name. Having a name is what makes the form easy to adopt. The understanding is the part that takes effort.

Feynman's Antidote

Feynman's prescription was simple: intellectual honesty. He called it "a kind of scientific integrity, a principle of scientific thought that corresponds to a kind of utter honesty." The first principle is that you must not fool yourself, and you are the easiest person to fool.

In software terms that means asking uncomfortable questions. Instead of "are we doing standups?", ask whether the standups are actually helping anyone coordinate. Instead of "do we have microservices?", ask whether the service boundaries are in the right places, and how you'd find out if they weren't. Instead of "are we Agile?", ask when the team last changed its process because the process wasn't working.

It also means being honest about what you don't understand. Adopting a practice because someone you respect recommended it is fine, as long as you know that's what you're doing and you're watching for signs that it isn't working in your context.

And it means measuring outcomes rather than activities. A team that ships reliable software and responds quickly to what its users need is engineering well, whether or not it has sprints and standups and story points. A team that performs every ceremony perfectly and ships late and buggy has built a beautiful bamboo runway.

The Practices I've Kept

I'm not arguing against practices; I'm arguing against unreflective adoption.

I try to make sure that every practice I follow has a specific, articulable reason behind it. When I can't explain why I do something, I take that as a signal that I might be cargo-culting it.

The Test

Here's a simple test for whether a practice is genuine or cargo cult in your team. Can the people performing it explain why they're doing it, in terms of the specific problem it solves for them?

Answers like "we do standups because Scrum says so", "we use microservices because that's the modern architecture" and "we write tests because best practices" don't count.

Compare those with this: "We do a quick sync each morning because the data pipeline team and the frontend team keep stepping on each other's database migrations, and this catches it before it becomes a merge conflict." That's a real reason, and it describes a practice that solves a problem the team actually has.

If you can't articulate the reason, you have two options. Work out what the reason is, or stop doing the thing. Either one beats carving more wooden headphones and waiting for planes that aren't coming.