Cargo Cult Programming is a methodological software anti-pattern in which developers include code in a system, but do not know or understand the reasoning why that code needs to be included; they only know that by including said code, the program works as intended.
The term originates from actual cargo cults, undeveloped South Pacific civilizations which saw people like the dude with the orange sticks below guiding airplanes with cargo (including food and clothes) onto their island, and assumed that it was the sticks themselves that summoned the airplanes, rather than the airplanes needing the person with the sticks (as you can tell, I have no idea what these are actually called).
What's more bizarre is that these cults continue to exist, even today.
The Rundown
- Name: Cargo Cult Programming
- AKA: "But this is how it has always been done."
- Summary: Occurs when a programmer ritually includes code in a system, despite not understanding how this code interacts in said system.
- Type: Methodological
- Common?: waves sticks
Tell Me A Story!
Meera is a new developer at my company. She's only recently joined my team, after a few months with another. We're getting her set up with all of our projects, with the necessary resources, with anything we think she needs to do her job, and all in all it's going pretty well.
That is, until we turned her loose on our code.
As with all our new hires (and particularly ones that are still junior) we usually start them out by giving them simple, independent tasks to work on. We did so with Meera. But the kinds of solutions she presented at first were just rife with cargo-cult thinking.
For example, she was asked to expose a new method on one of our Web API projects. She submitted something like the following:
public async Task<IActionResult> MethodName(...)
{
var resultTask = Task.Run(() => repository.InternalMethod(...));
var result = await resultTask;
return Ok(result);
}
Now this would be perfectly fine... except the "InternalMethod" is not asynchronous. In ASP.NET, if a method is not asynchronous, but you use Task.Run() to pretend it is, this is async-over-sync and does nothing to improve the performance or throughput of your application (and might actually make performance worse). But Meera included it because, in her previous group, all the method calls were invoked this way, regardless of whether asynchronous or not.
We asked her about this, and she said she figured that was just "how it was done." She had no idea what "async-over-sync" was, and once we explained it to her, it seemed to click. She fixed the method almost immediately, and made it more concise to boot:
public IActionResult MethodName(...)
{
var result = repository.InternalMethod(...);
return Ok(result);
}
It was very odd to live out cargo-cult programming in real life, seeing as I had had no previous experience with it (that I am willing to recall :) ). But once we explained to Meera what the issue was, she fixed it right away.
Turns out, that's the solution to the problem of cargo-cult programming: teaching.
Strategies to Solve
Lucky for us, cargo-cult programming is ridiculously easy to solve, but only if you have the right people. This problem can easily be fixed by people who have experienced other things.
In Meera's particular case, she came to my group from another, and as far as I can tell the entire group did what she did: coding everything asynchronously, whether it warranted such or not. When she moved to my group, we were able to instruct her differently. Knowledge is almost always the key to fixing any of the anti-patterns in this series.
But what about Meera's former group? How would you fix them? That depends entirely on who you are.
If you're another programmer in the same company, you might go talk to them, explain what you saw with Meera and suggest that they change their standards. This might work, but it just as well might not.
If you're in a position of leadership, or management, you might be able to foist this upon them. Doing so will probably make them do it, make them solve the problem of doing everything in asynchronous, but the cargo-cult attitude will persist, because unless you're a very persuasive talker the team is likely to have this attitude about far more than just this particular issue.
Surprisingly, the person who can do the most to fix this attitude is Meera herself.
People tend to learn the most from people they trust; like almost everything, this phenomenon is not unique to programmers. Meera's former team, as best as I can tell, liked her quite a lot in spite of her inexperience. If she were to show her team how they could do better, they are far more likely to listen. In this battle against the cargo-cult attitude, Meera is our greatest weapon.
Summary
Cargo-Cult Programming occurs when a programmer adds code to his project, despite said programmer does not fully understand what this code does (or even if it is truly necessary). It's relatively easy to solve, but only with the right people, the people from outside the cult that can gently persuade its members how to do better.
That person can then waltz away like a hero, and no one will blink.
Did you have to deal with a cargo-cult attitude? Did you fix it? I'd like to know, so get to sharing in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
