I have no idea how true the stories are, but legend has it that when supplies were dropped on some Melanesian islands during WWII, some locals took to replicating runway signs in order to further please the “gods” that were dropping them. They reportedly thought that making landing strips caused laden airplanes to visit. Richard Feynman later turned this into a metaphor about scientific theory – that if you don’t understand what you’re doing deeply, you may be fooling yourself.
I’d like to be a little bit more forgiving of adherents of technological cargo cults. Because the world around us is very complicated, we often just take things as they are rather than understanding them deeply, because there’s simply only so deep you can go into so many fields.
Is someone who doesn’t know the i386 machine language cargo-culting their way through a job as a web backend developer? Probably not. But from the perspective of an assembly-language programmer, any of us who write in compiled or interpreted programming languages are cargo-culting coding. You don’t need to understand a cell phone to dial home, but can you really say that you understand everything about how one works? Or are you just going through the motions?
So while some reliance on metaphor and “well, it worked last time” is perfectly normal, I think noticing when you cargo-cult is also healthy. It should also be a warning sign, or at least a flag to remind yourself that there may be dragons here. Or maybe just a buried learning opportunity, the X that marks the spot where digging deeper might be productive.
It’s not a bandwagon, it’s a rollerskate going down a steep hill and nobody’s wearing helmets or even kneepads, but they’re vaccinated.
I’ll trust peer review, you trust the non-peer reviewed, see who dies first.
And sometimes, someone has strapped a jetpack on them and gave the a little nudge.
There is a difference between applying and researching.
You can use an application (hard- or software) without understanding how it works in detail.
However, you must never ever confuse correlation with causation in scientific work – this is one of the most basic scientific principles. Which is injured countless times every day …
Such a wonderfully philosophical post.
Hey reader, have you ever tried to make your own bread? Like really make it from scratch? No buying *anything* at all that goes into making and baking it. It is near impossible to accomplish. Usage of technology (however simple it may be) requires individuals to specialize and specialization fosters abstraction. Without “cargo-culting” (lets keep calling it that) we are nothing. And as the post says we should be very aware and at the same time also thankful it is that way.
Inclined readers of original above post may also like the book: “How to Invent Everything: A Survival Guide for the Stranded Time Traveler” from Ryan North
Best captured by, “I stand on the shoulders of…”.
The YouTube channel “How to Make Everything” tackles this sort of making. It’s incredible the effort that went into making pancakes without buying anything already made or processed. Or making a knife starting with buckets of iron ore. The “Primitive Technology” channel does similar things. He made iron with materials found in the woods and a creek. Note that this involved building a forced-air furnace to reach the required temperatures, all from materials found on one plot of land using tools he’d made himself from this plot of land. What it takes to start from nothing is incredible.
At its logical conclusion even wheat you grow now is a byproduct of eons of selective breeding. Best I can come up with would be acorn flour from an oak tree but even that requires lye.
Or you could just kill an animal and eat that.
It’s not really saying “don’t think for yourself” if you read it? Just some mild musings on both the necessity to deeply verify fields, but the broad impossibility to do so with everything.
Unless if I’m talking with someone who’s created their own angle measurements, double checked math proofs, flat plates, independent angle measurement, charcoal/metal/semiconductor/plastic refining, mills, inferometers, semiconductor machines, boards, microprocessors/caps/resistors/etc, assembler, C compiler – to write a bit of C code from the bottom up, surely we can agree that to verify and double-check everything is a titanic task?
Generally, all one can do is know HOW to verify something so if something fishy comes up, you can investigate it.
We all rely on – directly or indirectly – tireless catalogues of accumulated measurements, ideas, and work.
TIL about cargo cult.
Blew my mind, made my heart hurt.
Replication Crisis is related I think. https://en.wikipedia.org/wiki/Replication_crisis
We have our sages that we rely on. They do discovery. They teach our scribes who write the compiler and docs. Then we all benefit from not really having to understand we just use the libraries and compiler.
We also have our independent verifiers. People who will dig in of their own motivation and gut/fact check our silicone by decapping it, our machine coders who can sometimes outsmart compilers, our repos of shared code with pull requests.
Hackers of all stripes are the immune system protecting tech from cargo cult and replication crisis thinking.
In HAD and at defcon the villages demonstrate many companies make products without fully understanding the implications of the decisions they make in the process. I’m sure they pay qualified people, but somewhere in the chain funding for completion gets cut off when bean counters and product launchers interrupt the full implementation of understanding of the product.
Agree
I consider myself fortunate to have grown up in the 80s, a time when you did have to understand how computers work. You don’t have to be an expert, I have a broad understanding of how a processor executes machine code, how registers are used and values are placed on stacks etc. That all helps to understand how something works without having to be an expert in all the details.
When it makes a big difference is when something doesn’t work. Having at least a basic understanding of how things work underneath helps you apply reason to a problem instead of just guessing.
Funnily enough I was discussing learning technology with someone the other day and discovered that my preferred technique is to start in the middle. By which I mean I never like to just use something at a superficial level, I like to know more about it beforehand and go from there.
For example when containers first started to become a thing, I didn’t just follow an example to run an application that was provided as a container image, I took the time to get familiar with docker as it was then, and things like how container images are produced. So from there over time I both learnt how to be a proficient user of docker and at the same time digging down into understanding the fundamentals of containers such as cgroups.
Some people like to start at the bottom and work up, others like to start at the top and work their way down the stack.
“I consider myself fortunate to have grown up in the 80s, a time when you did have to understand how computers work.”
The early 90s weren’t that much different, I suppose.
Programmers on DOS did sometimes use port accesses in Quick Basic, Turbo Pascal, etc.
There was int12h API/ABI, direct VGA programming in mode 12h, 13h, Soumd Blaster programming and so on.
Nice hack! Thanks.
This seems like a genuine problem that is being handwaved away as inherent/unsolvable. Why not just work on “flattening” technology (i.e. shortening the distance from raw material to finished product) so that it can be understood in its entirety?
This is a sloppy understanding of cargo cult programming. Using a high-level language like C or Rust isn’t cargo-culting from the standpoint of an assembly programmer: it’s accepting a trade-off between efficiency and readability.
Cargo cult programming describes using structures, syntax, development paradigms, etc without understanding what they do or when to use them. For example, copying a function to perform an operation without understanding what that function does or how to optimize it is an example of cargo cult programming. It’s a stage every developer goes through when they’re starting out; most of them grow beyond is as they getting experience.
Whoops! Sorry, Simplifier – I meant that as a comment on the general thread, not a response to you specifically.
This is actually where I wanted to go with this piece, and I probably will next week. I’ve got examples!
But I’ve got a feeling that there are corners of our collective computer lives where most people (“everyone”?) ends up cargo-culting it, perhaps because the systems in question are over-designed relative to their use and purpose, so they get far too complex to be understood by an end-user, and … well, there you go.
That is basically impossible – as the final user product consists of hundreds or maybe thousands of parts that are effectively sub products in their own right, and they have to. The benefits that come from higher complexity technologies are largely a product of its complexity…
I don’t think it’s impossible, as I’ve done it myself to some extent. Just work to reduce the number of parts, as well as the number of steps to create/assemble those parts, while still accomplishing the goal of the object itself. There are no benefits that come directly from complexity, only from complex objects (which do no necessarily have to be so).
Even the simplest computers – take a Z80 for instance has so much complexity in its creation. The silicon chips, requires a chemical processing industry, which requires other different resource extraction industry to the raw silicon. The PCB requires petrochemical industries to create the usual substrate, as well as metal deposition and etching, which again means new extraction and refinement methods to create those raw materials from rawer still materials. Then you get the case, the wire creation, all the passives…
The best you can do to simplify such a thing seems to me to be create the entire PCB and all the passives on the the silicon, then all you need is bond wires to the human scale peripherals. Which is still many specific technological requirements, and would make the whole thing ruinously expensive..
Then you get to the software that can run on a general purpose computer, and as soon as you go beyond a user with one program running on the bare metal entered manually you need an operating system and/or boot loader to select the programs to run from the data storage device (another complexity we haven’t even mentioned yet!), handle memory allocation, task schedules – you can’t have the benefits with the complexity.
It is certainly possible to deliberately or though lazy programing or part design add some complexity that is not actually required for the function, and so take that waste out. But stripping it down so from raw materials all the way to final product you can easily understand all of is pushing it too far. I’m pretty smart, as I expect are all the folks reading HAD – we wouldn’t read it if we were not curious and smart enough for the content on all this wildly different topics to mean something to us, but we can’t know enough to really understand all the steps in every chain from the rawest raw materials to finsihed products. Its too much.
So strip away the Z80 to flatten the complexity. Take the computer to figure out the prototype, and the microcontroller to work out all the bugs, then replace the microcontroller with something you can repair by yourself.
Or: put displays in the prototype cockpit (any, not specifically flying equipment) to figure out where to place the instruments, then throw out the display and put the real instruments when testing is finished.
You get the point, there are so many examples for complexity generating horrible results when something simple would be of better use. We should not put a digital frontend to the problems, we should solve them where they come from.
>Or: put displays in the prototype cockpit (any, not specifically flying equipment) to figure out where to place the instruments, then throw out the display and put the real instruments when testing is finished.
yes those sort of things I can see and agree with – and I didn’t say you can’t flatten anything – just that a great many things, pretty much anything that actually needs to be electronic/computer controlled really can’t be simplified all that far, unless its also the victim of really lazy creation. Heck replacing the computer in some cases isn’t even simplifying, arguably it is even making more complex – as the wires, levers, air pressure logic required to replace even very basic silicon is vastly more complex to produce, requires yet more specialists to really do correctly, with all the geometric relationships between the parts and precision requirements etc…
>Heck replacing the computer in some cases isn’t even simplifying
So keep going! What about replacing the task itself? Engineers often get stuck in the mindset of being told what to do, but you can always refuse. The ultimate goals of most technology are simple: move something from point A to B, let two people communicate, allow more efficient manipulation of materials X, Y, Z, etc. Go back far enough and you can achieve it with simple technology that everyone can understand. Then, once you’ve achieved simplicity, improve the technology as much as possible (without sacrificing said simplicity) and see where the balance falls between complexity and capability. So many things were designed without simplicity in mind, that you could (and I will) spend a lifetime re-engineering the world in this way. It’s worth the effort IMO. Why stand on the shoulders of giants when you could become the giant yourself?
The surely Z80 is an elegant/sophisticated design, but it isn’t overly complicated.
Here’s an XXL version that is able to function.
https://www.idealine.info/sharpmz/z80glass.htm
@Joshua that is why I picked the Z80 to make the point that despite it being simple enough you can at least plausibly understand how it functions electronically you still can’t understand all the complexities required to do the silicon fabrication etc properly. Its still too many hats for one person to have more than a extremely rough hand waving outline of.
@Simplifier
Just how much are you expecting ‘everyone’ to ‘understand’ – Identifying the right rocks and how to mine them efficiently so everyone can gather the raw material for whatever metal/mineral will be needed for the next process? How to process all these rocks into the required bits? how to then fabricate from these more processed raw bits the next subcomponents…
The only technology simple enough everyone can understand the full scope of it, and so do it properly is no technology at all – even something as seemingly primitive as stone tools has a learning curve to actually get anything close to your desire out of the currently incorrectly shaped rock, and then in use will likely be combined with any number of other skills to actually create the final tool you want.
Complexity for its own sake is to be avoided, but to pretend you can actually cut it out meaningfully in the modern world is to be delusional. We ain’t a population of as close to zero as makes no real odds hunter gather anymore (and even those native communities that avoided contact till recently all seem to have had very clear specialisms in the group anyway – so even they don’t all understand everything the group as a whole does!), and for the most part the developed world no longer has the biodiversity to really support the full spectrum of bushcraft skills to live like one anyway even if we were a small enough population…
@Foldi-One
So just give up? Allow overpopulation to push everyone into further and further layers of hellish complexity? What’s the end-game here? I’d rather at least attempt to design an understandable world. Also, always remember to reconsider your premises: if the population is in the way, maybe that’s what should change?
@Simplifier
Population control to the extent required to let us live a so heavily tech reduced life that ‘everyone’ could understand all of it is bonkers, and starts to sound rather Nazi… What are you going to do with the folks that are mentally incapable of understanding everything in your tech reduced world? Which could well include some of the smartest folks I’ve ever met – the pure math professor types for instance are often brilliant at seeing the patterns and logic to mathematics and completely disconnected from the real world in practically every other way..
I would also not say the population and complexity are directly linked, so while we do have a population growth problem globally its not the only element that drives more complexity, and arguably it also drives simplification as their are now more folks figuring out how to make improvements. But as part of the increasing complexity is that we are learning as a species – developing more understanding of the universe and putting that to use to learn yet more. Which is something we shouldn’t be trying to put the brakes on…
> pretty much anything that actually needs to be electronic/computer controlled really can’t be simplified all that far
But almost everything electronic or computer controlled around me doesn’t need to be computer controlled (and some of the things that actually could benefit from electronic control use mechanics instead: DC motors). In fact a good part of these programmable silicon flakes cause major inconveniences just by miserably failing to emulate what they replace, and they are by far more complex and fragile.
> But almost everything electronic or computer controlled around me doesn’t need to be computer controlled (and some of the things that actually could benefit from electronic control use mechanics instead: DC motors)
Sounds like you know how to buy bad products then, which will happen to us all sometimes, but for it to be almost everything in one direction…
Not that I disagree I did very specifically say ‘actually needs to be electronic/computer controlled’ for a reason – cutting out the computer where it is not needed is IMO great. As is keeping systems separate on their own little computers any processes that don’t need to talk – why have the infotainment system able to control the brakes basically all car makers of recent years it seems?!?!
> Sounds like you know how to buy bad products then
I don’t buy them, I have to work with them on the job … it is sad to see how much thought on how to build something was trashed in the last 40 years. Some recently applied changes seem to be made especially so introducing a computer may be sold as improvement later.
> Not that I disagree I did very specifically say ‘actually needs to be electronic/computer controlled’ for a reason
cool, I’m not used to not being disagreed with on this :)
Perhaps because I’m pretty strict with the “needs” part.
I don’t think its created to sell you the computer later for most things designed now, it created in a way to lock you into eternal monthly payments… The quality of the product and its easy of use come second to having the shiny brandname badge and ongoing cloud service fees to use…
Though that isn’t true of everything, even of everything sold at really good subsided by expected service income devices – The SteamDeck for instance is really well built hardware, pretty easy to replace parts on if you need to and has no lock in to the supplied OS (other than it being a surprisingly good experience for the handheld even in ‘desktop’ mode so you may not want to change). It’s being sold at a price that must be at best case break even for Valve. But still designed right, though of course it is a computer – so it can’t avoid being a computer…
Quite a bit of audio gear still seems to be done properly too, but I don’t really keep up with that (no real reason to). And I expect there are other industries out there that have not succumbed to the must own the client forever add cloud BS for no reason model.
I’m working on the railway in Germany, and obviously the industry doesn’t want to support the old installations any more. So the deciders shrink the existing to a level they can handle with the modern standard options (this process took at large scale place 40 .. 20 years ago). One big problem is that you have to explain a whole bunch of railway background to point out the resulting trouble; in the mechanical signal box (switch tower? Stellwerk) from the ’40s is about 80 years of constant debugging, and they do the job until today. You can test every single part by a little measuring, and basically produce replacement parts from metal square blocks. Then the mechanics were emulated with relais boxes, that worked pretty well, because it was done by people knowing how railway works (and it is at least possible to verify and repair the components). Now the relais are emulated by standard industry computers, and the standard industry doesn’t know about the now 150 years of debugging, and denies the needs of the basis (been there, done that, no t-shirt: “your problem is non-existent, because we are allowed to do it this way”). You cannot verify a computer or any chip, you have to buy it and trust the supplier that he doesn’t lie about it.
There were two benefits when updating to relais: automatic control of track clearance and remote controllability (the former is meanwhile refitted to the mechanical). Concerning safety the computers have nothing to offer that a relais signal box hasn’t. The managers were told, that changes could be made more easily, but that turned out to be a lie. There were tracks closed and big customers abandoned because it was impossible to keep it when going from relais to computer.
To regain full functionality one would have to go back to the mid-80s and then reapply the few changes that made actually sense. Same applies to rolling stock, same applies to customer service, and I’m pretty sure it applies to communication and other infrastructure as well. There is a whole lot of knowledge that is disregarded simply because it is older than 20 years, and it pretty much boils down to the computerization at all costs. What could possibly be learned from a time when computers didn’t even exist?
This is all sounding very much like the reasoning behind, you could do it with a 555! But you ask anyone who has always used microcontroller to do those tasks that were able to be done with a 555 to use that instead, and you just added a whole bunch of complexity to that person. You seem to treat complexity and simplicity as an independent and innate characteristic. But different things are complex to different people. You ask a guy from a village in the bush to make a fire with just some flint and whatever he can grab in the forest, he can probably do it without alot of complexity. Now you ask a near genius programmer to do it and they will probably fail while trying some complex setup because it’s not something they have had to think of before. Why not let the guy who wants to use flint do so, and the guy who wants to use his lithium battery powered arc lighter do so as well. One is way more complex, to the point that it would take a long time to learn every single aspect that went into the creation of it (lithium ion battery technology, the electronics, the plastic manufacturing, material science to make it not break immediately etc.) While the other is literally a rock found on the ground. I know that between the two I would choose the complex solution.
So don’t ask the genious programmer to make fire with a flint and don’t ask the bush man to do complex programming. Or better: let the bush man start the fire without requiring him to buy or create a fancy battery powered lighter, only because you as programmer are not able to imagine that the flint stone might serve the bush man much better than your lighter. Do not force digitalization upon the people who actually know how to do things outside a virtual reality (just use the virtual reality to figure out the best way to do the real thing).
so…”zen and the art of mortorcycle maintenance” vs “build it and they will come”?
“Cargo culting” doesn’t mean properly operating a mechanism without knowing how it works. Driving a car is not cargo culting if you don’t know its mechanics. You still get where you’re going. The tribesmen didn’t get any more airdrops (or did they? I wonder if people noticing what they built led to any foreign aid).
Most of our modern culture is cargo culting built around lost traditional wisdom but that’s a different story
Can you elaborate on that? How is modern culture cargo culting built around lost traditional wisdom?
And how does it not mean using something you don’t understand?
Abstraction and magical thinking are two different things. Cargo cultism falls under the latter.
I think the point is that there is an important difference between not understanding every aspect of how a thing is designed but still being able to use it effectively vs. not understanding cause and effect and thus not get the desired result. Abstraction is a useful concept.
Consider programming language standard libraries. Most programmers will not have looked at the source to fully understand how they work, and very few have any reason to. It is sufficient to understand the inputs and outputs in most cases.
Wearing ties for example.
Do you know where they came from and what was their point?
Does it has something to do with their phallic shape?
Here is a pretty good starting point: http://dresslikeagrownup.blogspot.com/2012/08/taking-stock-of-cravat.html
Evolution of existing neckwear? Changes in style? Keeping ones’ neck warm? Or are you referring to the meme that Victorians came up with them to hide those sexually suggestive buttons?
This is dumb.
We don’t know *anything* at a fundamental level. Even mathematics is eventually built on axioms. Even then we just kind of assume our rules of logic work.
There’s always another level. Waxing philosophical about the fact that some people dont go down to *your* level is pointless.
Oh you dont code assembly?
Oh you dont know the microcode?
Oh you dont know the processor architecture in detail?
Oh you dont know it at a gate level?
Oh you dont know it down to the FETs?
Oh you dont know the details of the fab process for the fets?
Oh you dont know the semiconductor physics behind the fet design?
Oh you dont know the atomic physics of the atoms?
Oh you dont know the subatomic physics of all the quarks?
Oh you dont have a detailed understanding of the mathematics of *pick your interpretation of standard model / string theory / etc*?
Oh you dont know how to build up our entire system of mathematics, through proofs, from the axioms?
At some point we just dont know, and NO ONE understands everything all the way down, and you never get anything done if you pursue it, other than the knowledge itself.
To operate in ANY capacity, you have to “cargo cult” 24/7 on EVERYTHING.
The joke is on you. You don’t have to “know”, rather you acquire the skill to “be able to know”. That is academic training.
Well our hominid ancestors didn’t have to have a PhD in veterinary medicine to know that when you stick the point thing in the big hairy thing it dies and you eat. “Well, it worked last time.” may be cargo culting, but “Well it works every time!” isn’t.
‘I know that I know nothing’
The more you know, the more what you know comes into the contact with the unknown.
It simply means to me that without our supply chains we are in deep SH…
I consider myself to be a cargo cult programmer when it comes to C and C++. I understand enough to copy a function from StackExchange, and can reason enough about the function to know that it will do what I want it to do, and update it as required if it won’t. But things like pointers, and even things like how/when to divide a program up into different files/modules is dark magic to me.
It’s a reflection, but the orientation is the same.
This article has nothing to do with cargo cults or cargo cult science.
The examples provided are more about abstraction and programming by coincidence.
Yeah, and if you could just go ahead and not turn “cargo cult”-ing into a verb, that would be great.
A cargo-cult was someone who emulated the actions of others (who had real understanding) to try to achieve the same outcomes as they did but without actually understanding WHY those actions worked.
This is why you see cargo-cult managers – they emulate the actions of successful managers by ‘having meetings’ or ‘using management terms’ without actually understanding why successful managers really do those things.
Same goes for tech – the real experts understand the tech all the way down – from chips, to machine language, to compilers, to other apps their code connects to, to data structures, and data transport…You can be a reasonable coder without worrying too much about the machine code and the chips they run on, but you’ll be a better coder if you understand some of it, and don’ blame slow code on being the fault of the hardware when its just crap code.
As a physicist and coder, I have a better understanding than most of how it all works, but I still rely on maths that is better understood by mathematicians.
Knowing what you don’t know, and not falling into the Dunning-Kruger effect is key.