The best term for this is Cargo Cult Development. Cargo Cults arose in the Pacific during World War II, where native islanders would see miraculous planes bringing food, alcohol and goods to the islands and then vanishing into the blue. The islanders copied what they saw the soldiers doing, praying that their bamboo planes and coconut gadgets would impress the gods and restart the flow of cargo to the area.
The issue of course is the islanders did not understand the science behind planes, Wallis talkies, guns, etc.
Likewise, cargo cult devs see what is possible, but do not understand first principles, so they mimic what they see their high priests of technology doing, hoping they can copy their success.
Hence the practice of copying, pasting, trying, fiddling, googling, tugging, pulling and tweaking hoping that this time it will be just right enough to kind of work. Badly, and only with certain data on a Tuesday evening.
I don't think of this as being cargo cult development. Cargo culting has more to do with mimicking practices that have worked before without understanding that they only worked within a broader context that is now missing. It's about going through motions or rituals that are actually ineffective on their own in the hopes that you'll get the results that other companies got who also happened to perform those same motions or rituals.
What OP is describing isn't like this because the thing being copied—the code—actually is effectual in its own right. You can test it and decide whether it works or not.
The distinction matters because the symptoms of what OP calls the Makefile effect are different than the symptoms of cargo culting, so treating them as the same thing will make diagnosis harder. With cargo culting you're wasting time doing things that actually don't work out of superstition. With the Makefile effect things will work, provably so, but the code will become gradually harder and harder to maintain as vestigial bits get copied.
I would almost call this the "boilerplate effect".
Where people copy the giant boilerplate projects for React, K8, Terraform, etc. and go from there. Those boilerplates are ideal for mid to large scale projects. And it's likely you'll need them someday. But in the early stages of development it's going to impart a lot of architecture decisions that really aren't necessary.
That's a great phrase. A perfect example of what you're talking about is actually built-in to the `helm` tool for creating re-usable kubernetes configs: `helm create myapp` creates the most convoluted junk I've ever seen in my life. As a new `helm` user I was extremely confused, as I had been expecting a minimal example that I could start from. Instead, I got a maximal example. Thankfully a more experienced engineer on the infra team confirmed that it was mostly unnecessary boilerplate and I could remove it.
Something to consider for anyone else building tools — boilerplate has costs!
Seeing this exact effect where I am currently working. Main available CI/CD tool is a customised and centrally managed Jenkins fleet. It's pretty much impossible to avoid using and seldom needs changed - until it does. Some attempts have been made at centralised libraries and patterns - but even that requires knowledge and study that most won't know is available or be given time to acquire.
So when the inevitable tweak or change is made it's made in the easiest, cheapest way - which is usually copying an existing example, which itself was copied from somewhere else.
I see exactly the same in other teams repositories. Easiest path taken to patch what already exists as the cost/benefit just isn't perceived to be there to worth prioritising.
> only worked within a broader context that is now missing
> because the thing being copied—the code—actually is effectual in its own right.
I don't understand how the second disproves the former.
In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal I find that belief is at the root of a lot of cargo cult development. Where many programmers glue things together say "it works" because they passed some test cases but in reality code shouldn't be a Lovecraftian monster made of spaghetti and duct tape. Just because your wooden plane glides doesn't mean it's AC an actual plane
But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.
Sorry, the quotes around "work" were implicit. I thought there was enough context to make that clear. That just because some things actually work doesn't mean it works for the reason it actually works.
This is what I meant by cargo cults working. Where there is a _belief_ in a causal connection where there is none. The Melanesia really did believe there was a causal connection between their actions would cause cargo to return. It's not just about appearance. It is about not understanding the actual causal chain and misinterpreting the causal variables.
Measurement is HARD. It is very common that if you do A then B will happen YET A is not the cause of B. Here's a trivial example: a mouse presses a button and it gets fed. In reality, the mouse presses a button and a human feeds the mouse. It is not the button. It may even be impossible for the mouse to know this. But if the human leaves, the mouse can press the button all they want and they will not get fed. I hope you can see how this can happen in far more complex ways. As the chain of events gets longer and more complex you an probably see why it is actually a really common issue. Because you have literal evidence that your actions are causal while they are not.
For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked.
Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a helpful one imo.
Concrete examples of what I think actually counts as cargo culting:
* Incorporating TDD because it's a "best practice".
* Using Kubernetes because Google does it.
* Moving onto AWS because it's what all the cool companies are doing.
The key thing that makes cargo cult development a cargo cult is that it's practices and rituals adopted without any concrete theory for what a bit is supposed to do for you in your context. You're just doing it because you've seen it done before.
This is different than small scale copypasta where people know exactly what they're trying to accomplish but don't take the time in any given instance to slow down and re-analyze why this bit of code looks the way that it does. They know that it works, and that's enough in that moment.
If we're going to go back to the original analogies that started it all, what you're describing as cargo cult would be more similar to islanders using machinery that was left behind without knowing how it works or how to maintain it. They don't strictly need to know that in order to gain actual concrete value from the machinery, but it would be better in the long term if they knew how to maintain it.
Right, yes, exactly this. Using a tool or process without full understanding of its operation, or how to use it in different ways, is not _ideal_ - but it's a different thing (similar! but different) from "doing something just because everyone else is doing it". A Makefile-copier might not know the full stack of concepts that undergird their working configuration - but they do know (in the "true justifiable knowledge" sense) that it _is_ a working configuration, and they know why they're adopting it.
Hmm, fair, my definition certainly doesn't apply to CCD ("we do it because Google does it") - but I still maintain (as a child commenter elaborates) that there's a difference between "the reason I'm doing this is because other people do it" and "the reason I'm doing this is to achieve my given aim. I don't the exact functionality by which this leads to the aim being achieved, and I might not be able to modify this to achieve other aims - but I do know that it will get me where I want to go".
Neither is ideal - but, the latter is much less harmful IMO.
I'd say it is true for both. There's evidence that the actions cause the events. They correlate. It's why people start doing the actions in the first place. The exact reasoning you use, if it didn't "work" (appear to work) then the cult dies off pretty fast (and they do). Rationally irrational. It's good to be aware of because with high complexity systems it is easy to fall into these types of issues. Where you are doing A and you _believe_ are causing B, but there is no real relation.
> Just because your wooden plane glides doesn't mean it's AC an actual plane
But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island, what you're doing is definitely not cargo culting.
It might not be actual engineering, maybe you don't understand aerodynamics or how the engine works, and maybe the plane falls apart when it hits the runway on the return flight, but if you got the cargo back you are doing something very different from cargo culting.
That's why copypasta doesn't count as cargo culting. It accomplishes the same task once copied as it did before. It may do so less reliably and less legibly, but it does do what it used to do in its original context.
>> Just because your wooden plane glides doesn't mean it's AC an actual plane
> But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island
Sure, but these are categorically different and not related to my point.
> That's why copypasta doesn't count as cargo culting.
Let me quote wiki[0]
The term cargo cult programmer may apply when anyone inexperienced with the problem at hand copies some program code from one place to another with little understanding of how it works or whether it is required.
Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Some examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion code for objects that garbage collection automatically collects.
Even in the example it gives the code will "work." You can collect garbage when the language already does that, you'll get performance hits, but your code won't break.
It "it doesn't _work_" disqualifies something from not being cargo cult programming, then there would be no cargo cult programming. Who is shipping code that doesn't compile or hits runtime errors with any form of execution? You couldn't do that for very long.
Let's take an airplane example. Say you want to copy Boeing[1]. You notice that every 747 has a coffee maker on it. So you also make a coffee maker. After all, it is connected to the electrical system and the engines. Every time you take out the coffee maker the airplane fails. So you just put in a coffee maker.
A cargo cult exists BECAUSE _something_ is "working". BECAUSE they have evidence. But it is about misunderstanding the causality. See also Feynman's "Cargo Cult Science"[2]. As dumb as people are, there's always a reason people do things. It is usually not a good reason and it is often a bad reason, but there is a reason. Even people will explain you "causal" explanations for things like astrology.
> not only what you think is right about it: other causes that could possibly explain your results
His explanation explicitly acknowledges the experiment works. In fact, even the math to explain the experiment "works". But it is wrong. Related is Von Neuman's Elephant. Where Freeman Dyson had evidence that a theory explained an experiment, yet it was in fact wrong. Evidence isn't sufficient to determine causality.
To quote the original source that Wiki cites and is derived from:
> A style of (incompetent) programming
dominated by ritual inclusion of code or program structures that
serve no real purpose. A cargo cult programmer will usually
explain the extra code as a way of working around some bug
encountered in the past, but usually neither the bug nor the reason
the code apparently avoided the bug was ever fully understood
(compare {shotgun debugging}, {voodoo programming}).
This is categorically different than the kinds of copypasta that TFA is talking about, and it's different in that the copypasta in TFA does serve a purpose.
There's a world of difference between copying something whose implementation you don't understand but whose function you do understand versus copying something which you vaguely associate with a particular outcome.
This is mentioned in footnote 1. Concretely, I don’t think this is exactly the same thing as cargo culting, because cargo culting implies a lack of understanding. It’s possible to understand a system well and still largely subsist on copy-pasting, because that’s what the system’s innate complexity incentivizes. That was the underlying point of the post.
For me, there are many cases where I copy-paste stuff I've written in the past b/c some tool is a pain-in-the-ass and I can't afford the mental context switch. I usually do understand what's happening under the hood, but it's still cognitively heavy to switch into that "mode" so I avoid it when possible.
Tools that fall into this category are usually ops-y things with enormous complexity but are not "core" to the problem I'm solving, like CI/CD, k8s, Docker, etc. For Make specifically, I usually just avoid it at this point b/c I find it hard to avoid the context switch.
It has nothing to do with miraculous incantations--I know the tradeoff I'm making. But it still runs the risk of turning into the Makefile Effect.
It’s always hoped (but rarely shown to be true) that by making templates, teams will put thought into their K8s deployments etc. instead of just copy/pasting. Alas, no – even when the only things the devs have to do is add resource requests and limits, those are invariably copy/pasted. If the app gets OOMkilled, they bump up memory limit until it doesn’t. If it’s never OOMkilled, it’s probably never touched, even if it’s heavily over-provisioned (though that would only matter for the request, of course).
This has spawned a cottage industry of right-sizing tooling, which does what a dev team could and should have done to begin with: profiling their code to see resource requirements.
At this point, I feel like continuing to make things easier is detrimental. I certainly don’t think devs need to know how to administer K8s, but I do firmly believe one should know how to profile one’s code, and to make reasonable decisions based on that effort.
I do know how to profile my code, and I'll also continue to bias towards not doing it now. Even if it could mean more pain later.
I think part of the problem is that the pain it causes is quite visceral, but the opportunity cost is pretty abstract, so it's a lot easier to just focus on the pain and forget about what you're gaining.
I agree, and I think the key distinction is in understanding. In a cargo cult there's a lack of understanding, whereas I'll often copy and paste code/config I understand to get something done. Usually this is for something I don't do very often (configuring nginx, writing some slightly complicated shell script etc.) I could spend an hour reading docs and writing the thing from scratch but that's likely gonna be wasted time because there's a good chance Im not going to look at that thing again for a few years.
And of course every one of those tools has to have their own special language/syntax that makes sense nowhere else (think of all the tools beyond make, like autotools, etc)
I don't care about make. I don't care learning about make beyond what's needed for my job
Sure, it's a great tool, but I literally have 10 other things that deserve more of my attention than having my makefile work as needed
Honestly is this not how it should be done? There's always going to be a more elegant approach for sure. But in general, we don't want developers to keep rewriting the same code again and again. Avoiding that is part of entire design paradigms. I'd like to talk to the dev who doesn't copy-paste and writes everything from scratch.
The article does kind of mention this in footnote '1', for what it's worth:
> The Makefile effect resembles other phenomena, like cargo culting, normalization of deviance, “write-only language,” &c. I’ll argue in this post that it’s a little different from each of these, insofar as it’s not inherently ineffective or bad and concerns the outcome of specific designs.
I think I fall very much into the "beginner of beginner stages" of understanding programming. It sounds like then, if I want to avoid that "cargo cult" mindset, then a structured flow of:
Does this then mean that, if someone truly wants to "escape the island, and fly the plane" as it were, it comes down to "university is the 'truest' way"?
Note: Yes, I realize it's hard to speak in absolutes, that there are plenty of exceptions to generalities, and that all people have various degrees of justifications of I-can't-do-that-itus; I'm talking more in terms of optimal theory. That, the optimal route to avoid cult-like behavior is to understand the whole thing, and that "the whole thing" comes from higher education, right?
Logically at least, it would seem that even diligent studying with books as a means to meet/surpass the "completeness" of university would still be... inadequate in some regard when compared to in-class time with learned educators. (Again, supposing that the same person worked just as hard doing either option, etc.)
An engineer should learn first principles and master the tool rather than dancing around it or reach immediately for replacing it with something else. This is why the "replacement" tool "just" is fundamentally terrible because it doesn't do dependency checking and optimizes for the wrong things. Instant loss of efficiency throwing away the power and simplicity of makefiles (GNU extensions often needed).
Instead, (GNU or vanilla) makefiles are ideals for very simple, portable projects. Make is everywhere.
For anything complicated, a proper build system that doesn't use autotools like cmake or bazel.
The issue of course is the islanders did not understand the science behind planes, Wallis talkies, guns, etc.
Likewise, cargo cult devs see what is possible, but do not understand first principles, so they mimic what they see their high priests of technology doing, hoping they can copy their success.
Hence the practice of copying, pasting, trying, fiddling, googling, tugging, pulling and tweaking hoping that this time it will be just right enough to kind of work. Badly, and only with certain data on a Tuesday evening.