Cargo Cult Software Engineering

Last year, a mentor of mine recommended I read Richard Feynman's 1974 commencement address at Caltech. It's about what Feynman called "cargo cult science," and 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 and the planes stopped coming, 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. But no planes came.

Feynman's point wasn't about the islanders. It was about scientists who follow the rituals of scientific inquiry (the conferences, the papers, the methodology sections) without the intellectual honesty that makes science actually work. They do everything that looks right. But the planes 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.

But when you adopt the practice without understanding the underlying reason, you get cargo cult engineering. You get the bamboo runway. You get the ritual without 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.

Lifting a practice from one context and dropping it into another without understanding why it works is exactly the cargo cult problem. You've built the runway. But the planes aren't coming because the planes were never about the runway; they were about the logistics network, the supply chain, 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 licenses and having a certified Scrum Master run your ceremonies. The form is immaculate. The substance (the willingness to adapt, to communicate honestly, to deliver working software frequently because you care about the outcome) is often completely absent.

Microservices are another example. Amazon and Netflix decomposed their monoliths into services because they had specific scaling and organisational problems that monoliths couldn't solve. They did it gradually, painfully, over years. But the industry cargo-culted the result: "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. The name makes it easy to adopt the form. 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, this means asking uncomfortable questions. Not "are we doing standups?" but "are our standups actually helping us coordinate?" Not "do we have microservices?" but "are our service boundaries in the right places, and how would we know if they weren't?" Not "are we Agile?" but "when was the last time we changed our process because it wasn't working?"

It means being honest about what you don't understand. If you're adopting a practice because someone you respect recommended it, that's fine, but you should know that's what you're doing, and you should be watching for signs that it's not working in your context.

It means measuring outcomes, not activities. The team that ships reliable software and responds quickly to user needs is engineering well, regardless of whether they have sprints or standups or story points. The team that performs every ceremony perfectly but 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 ensure that every practice I follow has a specific, articulable reason. If I can't explain why I do something, that's 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?

Not "we do standups because Scrum says so." Not "we use microservices because that's the modern architecture." Not "we write tests because best practices."

But: "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. That's a practice that solves a problem the team actually has.

If you can't articulate the reason, you have two options: figure out the reason, or stop doing the thing. Both are better than continuing to carve wooden headphones and waiting for planes that aren't coming.