Introduction
The term cargo cult programming is harmful to programmers as a whole. It discourages learning through imitation even though that is the fastest way to expertise. The term itself even misses the mark and in doing so starts devs down a path of never ending reinvention. I want to look a bit deeper into these terms origins and how it's applicable to programming today.
Cargo culting
Cargo cult programming is defined as using others code without understanding what it's doing. Ironically, this definition in itself is a good example of the rampant amount of cargo culting in the programming community. Copying others is very important to gaining understanding and expertise.
So what is the cargo cult? It's largely credited to native islanders in the Pacific during World War 2 but the phenomenon had been decades prior. When the armies came to the island they would distribute cookware, clothes and other supplies to the native people. When the war concluded and the armies left the island, the villagers still wanted to trade! So they started to do imitate the foreigners. They would build runways and set up a control tower. They put coconuts on their ears to mimic the headphones and waved batons around to try and make the planes land once more on the island. In describing people, cargo cult is quite an inaccurate term and has been distanced from. That said, I could not find any suitable replacements yet.
That aside, in the 1970s, Richard Feynman gave a speech describing cargo cult science. He described scientists that are not rigorous enough in their pursuit of the scientific method and cited intellectual dishonesty as the core trait of cargo cult science. Certain actions like embellishing results, or using another researchers data were cited by him as being the hallmark of the term.
Imitation
The easiest way to improve your skill sets is to imitate people that are further along in their learning. If someone is getting results, and you are not, it makes sense that by performing the actions in the same way will lead you to improve your outcomes. Established industries and sports already have many years of history behind them. This history is not worthless. IBM is over a century old, HP approaching that. Apple and Microsoft are coming up on their 50th anniversary. Even Facebook is old enough to drive these days.
As software developers, we like to think of our problems as unique. And perhaps they are unique applications, but the underlying tech has frankly been created before somewhere. The problems have been solved in a variety of different ways utilizing different values and technologies. Learning about these previous solutions is vital to ensuring we arrive at the best solution for us in that moment and set of circumstances.
Examples of cargo cults in programming
Imitating is not cargo culting. Even using someone else's code without understanding is not cargo culting if it works. In order to rise to the level of cargo culting is that we use code or processes in the wrong way, with bad results, and delude ourselves into thinking we are experts or that it's working.
Coding example
Let's look at a concrete example in the Ruby community, Sidekiq. I'm picking on the gem a bit here but this sort of example can be found everywhere in the development community. On the gem documentation we find this nifty little chart.
The essence of this chart is "look how much faster I am". Anytime I see this I always ask "What conditions did they skew to get this result?". I then make some sort of generic litmus test to see if it really matters. This particular chart shows that if I have jobs that have no code in them, sidekiq is a lot faster. But how often do we run background jobs with no code in them? Hopefully never. This benchmark is completely useless to any real world scenario.
Let's say that the code in my job takes 500ms to run. Sidekiq will use .14ms to pick up the job. On the other hand Resque will take 4.1ms. Thus we need to compare the 500.14 to 504.1. Switching to Sidekiq may pick up .79% or so in performance. This is hardly worth a large engineering undertaking to switch from one to the other. In addition, Sidekiq makes a large amount of tradeoffs to reach this speed. That's an article for a different day but for this one, it's important to not only understand the benchmark results, but the options and pros/cons of those set of options.
Now I get in some ways it's not quite that simple. But that's the importance of real world testing. If you in the past have argued something is faster based on other peoples benchmarks, you participated in cargo culting.
Process example
Let's talk about SCRUM. Terminology is important here. I am referring to the SCRUM process in particular and not scrum, the agile term. We all know scrum (hopefully, if not go read up on it). It's sprints with plannings and retros as well as the daily standup and scrum masters and as a dev you roll your eyes. Most teams that utilize SCRUM do not do so effectively. So why is this? In an ironic way, the very answer is in the agile manifesto where the first creed is:
People and interactions over processes and tools
As an agile company you should find the interactions that work for your company. From there, give that set of interactions a name or a label. It may be SCRUM. But it may be something completely different. Agile is about having a specific set of values, communication instead of self-reliance, teamwork over individualism. Without the core values, the team will be much less likely to be agile.
Expertise
And so that brings me to the final point. If SCRUM is supposed to make your agile, but SCRUM in itself does not jive with agile principles, why is it pushed so hard? The more cynical devs out there will just dismiss it as another pointless process. However, the goal is that for a team that utilizes SCRUM, eventually (hopefully) the underlying values sink in.
Sprint plannings are to emphasize breakdown, communication, and planning, daily stand-ups are intended to force interactions every day, retro's to have a time to learn continuous improvement.
It's important to note that SCRUM is the starting point, not the ending point. By implementing or rolling out SCRUM or it's variations like SAFE throughout your organization, that is only the very beginning. If you stop there you are not agile yet. However over time, hopefully the agile principles sink in. How can you accelerate this? Supplement your team with agile experts. I don't mean certified SCRUM masters and all that jazz with fancy terminology. I mean people that really understand people and interactions throughout the company.
I'm going to be adding a lot more content on expertise in the near future since it's a massive topic to unpack. Experts have a large amount of knowledge. They might have decades of experience or study behind them, practical and even contradictory experiences and wide and perhaps even conflicting opinions on some topics. It's important to note that SCRUM is born from agile expertise. However it's dehydrated advice. The vast amounts of knowledge that went into creating it can't as easily be communicated.
There was a recent study that showed humans can talk at about 39 bits per second. I find this interesting to think about how we approach out interactions with people. If someone has the equivalent of 1 GB of data in their head, it will take way longer than if someone has 1 MB of data in their head. A constant in communication is time. Meetings are often short. Recognizing expertise is hard and often maligned. If the 1GB person and 1 MB person are in an hour meeting, often the 1 MB person is going to sound more knowledgeable. They can easily communicate their complete thoughts on the topic. The 1 GB person on the other hand has to pick through a much larger data set, figure out what to deliver and when it's delivered it often seems confusing because the nuance doesn't get distilled in short term periods. They may seem indecisive, or contradictory, or meandering.
SCRUM the process is only the 1 MB version of scrum the idea. It's really up to you to expand on that core of data with your own experimentation and data sets to reach a state of agility.
Conclusion
Imitation is not a bad thing. However don't just do the same things and expect to call yourself an expert. Imitation is a starting point to further understanding. Abstract processes are just the start. No matter what process you implement, until the underlying mechanics are understood it will not be super effective. Avoid cargo culting by doing your own thinking and hypothesizing. Don't rely on claims made on a blog or published by the authors. (A fun one is every HubSpot article has their product as #1 even though it's generally the worst on the list). If you implement a process, understand that just following it blindly is not the best way to results.