Writer and blogger Alex Ewerlöf has written a discussion of cargo cult programming, including a bit of background on the term itself.
Cargo culting refers to a phenomenon where people imitate the superficial aspects of a practice or process without understanding the underlying logic or reasons behind it.
Although the term originated from historical events, its usage expanded to other areas like software, systems, and organizations.
Here's the story of how cargo cults came to be, with some examples from software and corporate world. In Pro-Tips we discuss actionable insights to prevent, spot, and dismantle cargo culting in your organization.
🤖🚫 Note: No AI is used to generate this content or images.
It's apparently a problem which keeps coming up repeatedly. What examples of cargo cult programming, if any, have soylentils encountered (or caused) over the years?
(Score: 1, Insightful) by Anonymous Coward on Tuesday November 19, @05:51AM (6 children)
Throw around that much jargon w/o context and your head starts to spin.
(Score: 5, Interesting) by Sourcery42 on Tuesday November 19, @03:44PM (3 children)
I work with a guy like this. He can contribute to any conversation, and it is truly meaningful contribution, not just slinging around buzz words and business speak with no concept of what it actually means. He is super knowledgeable on a broad base of topics. He could be so valuable...but he's not. His actual work output has zero substance. He's a highly compensated employee who does nothing but sound smart in meetings and generate work for other people.
(Score: 4, Touché) by Fnord666 on Tuesday November 19, @09:53PM
I hope I'm not the guy you're talking about!
(Score: 3, Funny) by donkeyhotay on Wednesday November 20, @01:22AM
I think I know that guy. I wonder if we work at the same place :-)
(Score: 3, Funny) by aliks on Thursday November 21, @02:51PM
There are a lot of guys like that. So many that they have a name - High Planes Drifters.
They engage with the BIG projects to give them the benefits of their wisdom, buy somehow, drift onwards before they are called on to deliver something . . .
Now excuse me, there are some other major threads that I have to attend to.
To err is human, to comment divine
(Score: 3, Touché) by epitaxial on Tuesday November 19, @05:14PM
My first thought was AI wrote the article.
(Score: 2) by driverless on Wednesday November 20, @02:26AM
It's also a non-sequitur, he first paraphrases the Wikipedia article on cargo cults and then gives various examples of devs and managers chasing the fad of the day... which has nothing to do with cargo cult programming. The second half, with a bit more detail added, would probably work on DailyWTF, but it doesn't follow from the first part.
(Score: 5, Interesting) by DrkShadow on Tuesday November 19, @06:41AM (5 children)
"Micro" services - with obscenely macro overhead
- sidecar proxies (not least for tracing)
- security scanners (one for each pod? pod type?)
- a friend told me the other day that they put artificial limits before each one to prevent unexpected OOM errors -- "three layers" of checks (including concurrency, as measured by the service itself)
- separate logging systems, interacting with the multitude of services
- very macroscopic scheduling overhead, communications overhead, monitoring, status checking, scaling, ....
- improperly set resource requirements for an ever-increasing number of services
- services that are no longer used not getting turned off
I mean, 50 relatively large compute nodes for what I say could be done on my desktop PC. Maybe two.. maybe. To say that "Micro services" is a _worthless_ cargo-cult would be amazing -- in actuality, it's actually highly, highly detrimental. However, people just espouse its theoretical greatness at the top-most layer.
Eventing: perfect.
A micro service for each event type: your company is going to go through existential crisis.
ugh.
(Score: 5, Funny) by jasassin on Tuesday November 19, @07:07AM
Sounds like they need systemd.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 4, Interesting) by VLM on Tuesday November 19, @02:40PM (3 children)
Large system code golf where the goal is not to produce a working cooperative system but to prove the cause of the problem is somewhere else.
Its a big corporate bureaucracy architected into code.
"Did you get the memo about the new TPS report headers? I'll send you another memo." All that matters in life like that, is being able to prove you're not to blame for the TPS report headers being wrong.
Hence the extensive logging for blamestorming purposes.
The entire purpose of the system is to enable the ops, database, and frontend teams to all blame each other for everything.
Also if nothing ever gets fixed then they can't downsize anyone because they need everyone.
(Score: 3, Funny) by Anonymous Coward on Tuesday November 19, @03:39PM (1 child)
Sounds like the last place I worked. The only way to survive was to get in the pipeline passing on messages "from above". If you were the end of the line then you got to do all the work. Everybody there had learned this, whereas I went in with the idea that we were working together as a team. Because that's what the happy faces on the website and all the management said. Apparently not! So your choices are (a) get in the pipeline and find another sucker to fwd to (b) do all the work yourself with 7 layers of oversight "unimpressed with your slow progress".
(Score: 3, Insightful) by Fnord666 on Tuesday November 19, @09:56PM
Sounds just like an MLM scam.
(Score: 2) by JoeMerchant on Wednesday November 20, @12:57PM
For us it's software vs hardware. If the software does enough logging it can eventually prove that the problem lies in the hardware...
To be fair, all that logging initially shows the software screw ups, but we fix those...
🌻🌻🌻 [google.com]
(Score: 3, Funny) by jasassin on Tuesday November 19, @06:58AM (3 children)
This guys a poser.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Tuesday November 19, @08:17AM (2 children)
The correct term is Wanker.
(Score: 4, Touché) by Tork on Tuesday November 19, @03:08PM
Knock it off or I'll wank you.
Wait, no I won't.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2, Funny) by Anonymous Coward on Tuesday November 19, @03:14PM
Language, Timothy!
(Score: 3, Informative) by Anonymous Coward on Tuesday November 19, @12:21PM (1 child)
Here's the original famous commencement speech [caltech.edu] from Feynman that popularized the phrase 'cargo cult' as applied to science.
(Score: 0, Flamebait) by Anonymous Coward on Tuesday November 19, @03:48PM
Feynman (and other celebrity scientists) live in a bubble. They are not subject to the same economic forces the rest of us are. In the real world, the customer (the rich guy) is always right. Showboating your rationality - even if it is better than average - is the privilege of somebody who in is actual fact shifting product in the form of university courses, student apartment rentals and branded merch.
Every "decent" university needs a celebrity or two who live in a false universe where their new ideas about the structure of spacetime is rewarded. It's not. Sell the merch, close the deal, move onto the next pitch.
(Score: 4, Insightful) by Rich on Tuesday November 19, @12:44PM (5 children)
That the guy is slinging bullshit lingo might be due to the fact that he had to experience such stuff. Anyway, the worst case of cargo culting I have seen were "code reviews". Given the discussed superficial approach, these were major time wasters spent with bikeshedding about style issues like variable names in a room full of developers on the clock. I've come to the conclusion that, for a proper review, the reviewers have to properly understand the code base. In my experience, the most simple path to provably achieving that level is successfully and cleanly implementing a feature that requires structural architecture work, in the order of 4 to 8 man weeks. However, again in my experience, a good part of developers aren't even able to get there, and those who get there feel reviews to be a torturous chore running against their desire to express themselves with new productivity, so they avoid diving fully into review work.
A great amount of money would be required to compensate the pain that the "decent" developer feels, and it doesn't flow. So developers that can successfully review on standard wages are a rare breed. They probably have to have SM traits, masochistic in a way that they are eager to occupy their intellect with the inferiority of others, and sadistic in a way that they can demonstrate this inferiority of others with the results.
(Score: 4, Informative) by pkrasimirov on Tuesday November 19, @06:22PM (4 children)
Lol they are doing it wrong. When "code review" is seen as approval process then it becomes what you describe. The original meaning is to help the developer who seeks code review, as in "help me find my bugs before they hit prod". It's a take-it-or-leave-it feedback. Someone doesn't like my variable names? Noted, thank you for your time, next. If they want me to change something they have to persuade me, as in increase my knowledge on the matter so I would know better and avoid it myself. All this provided I'm willing to spend the effort to learn that particular info. This approach immediately makes it obvious why cooperation and teamwork is essential, not so much "rules". Mandatory approval by two others before merge? Hey Jack and Jill, click here please and I'll return the favour on your PRs. Express way to bloat the codebase with half-ass garbage.
/rant
Aaah, developers.
(Score: 2) by JoeMerchant on Wednesday November 20, @05:50PM (2 children)
Code review is for finding actual problems first, then potential improvements.
If the improvement isn't worth the time it takes to implement, then so be it. "Potential improvements" like you don't like the style of my variable names - yeah, noted. Then there was the "potential improvement" where we sped up the bottleneck of our application 100x taking it from 200 minutes execution time down to 2. Pretty much fits the definition of "worth the time."
In our industry, the main concern is finding actual problems with those extra eyes on the code.
🌻🌻🌻 [google.com]
(Score: 2) by Rich on Thursday November 21, @05:17PM (1 child)
Well, that's exactly what the cargo cultists try to achieve. But as I laid out, under normal corporate conditions, it won't work.
(Score: 2) by JoeMerchant on Thursday November 21, @06:37PM
> under normal corporate conditions, it won't work.
With the normal time pressures, three more meetings to go before quitting time, etc. yeah, nobody has the attention span to do a real code review.
With my current globally distributed working from home team? We actually do some pretty productive code walk throughs (won't call them reviews, because nobody likes doing the paperwork to make them official documented reviews) - we find stuff, actually understand what each other are doing, etc.
In my experience, well targeted code walk throughs, or reviews, that cover less than 10% of the code base, can deliver over 90% of the value of "complete" code reviews - that "completeness" just obliterates the practically available attention span and means that reviewers are skimming, rather than diving.
🌻🌻🌻 [google.com]
(Score: 2) by PiMuNu on Thursday November 21, @09:21AM
It's a layer of quality check. Is the dev writing decent code or cutting and pasting from stack overflow? Is the dev writing adequate unit tests? Etc. And yeah, style guide as well (no, please don't just call all of your variables x1, x2, x3, ... thanks).
Your line manager is responsible for your code, they need to check that it is decent quality.
(Score: 3, Insightful) by VLM on Tuesday November 19, @12:47PM (10 children)
In the old days, once you learned a little FORTRAN, you saw it everywhere (back when the old timers mostly learned FORTRAN initially). I suspect people of the "home computer" BASIC generation are equally visually obvious.
Another example I can think of in the old days was write your normal imperative / functional-ish program then very lightly wrap it in OO and call it an OO design. You can, given a lot of time, incrementally convert it to OO this way but it's probably going to take longer than simply starting over.
(Score: 0) by Anonymous Coward on Tuesday November 19, @01:25PM (7 children)
WTF is this guy talking about?
(Score: 5, Interesting) by VLM on Tuesday November 19, @02:07PM (5 children)
Well, hilariously, in the modern era you assume that like all other languages you define the type of a variable by stating pretty early in the program that variable named "wtf" is an integer or float or whatever. In the old days, FORTRAN had a much funnier way to define variable types, the first letter of the variable name, aka implicit typing. So if you want an int aka integer you name the variable IIRC beginning with I J K L M or N. Everything else is a REAL aka a float or double. Life's easy if you only have two-ish variable types. So you can look at "old FORTRAN programmers" writing modern lanugages and all their integer variables begin with I J K L M or N. No, buddy, you don't have to name ints that way anymore, not for a long time. For a VERY long time in the 80s it seemed like all "for" loops used a variable named I to count, because "FORTRAN".
As for OO you can take plain old imperative code wrap it in a class named myLittleProgram with a method name of run() and the "OO" in your design amounts to running myLittleProgram.run(). You're supposed to develop OO programs by methodical design of data structures and work your way up. Or you can just write an entire imperative system, wrap it, ship it, call it good. Its kind of like if you are forced to use a strongly typed language like Scala for type safety and you're like "F type safety" you can just define all your variables as type "Any" and pretend to enjoy all the gains of type safety despite not actually having any. "we write OO here" and you find out the entire program is one class with one method, or "we write strongly typed here" and you find out all the variable declarations are type "Any" seem cargo cultish to me.
(Score: 3, Interesting) by Tork on Tuesday November 19, @03:30PM (2 children)
I found this really fascinating. I'm sorta on the other end of this tale, I work in a scripting language that's proprietary but if you set your IDE's parser to "Javascript" you'll be in decent shape. This scripting language was developed to automate some software. Ummm... think about how Excel uses VBScript or something like, this isn't much different.
One day I discovered an array I was using had more elements than it was supposed to. I did not find out why but I did discover that if I cleared the array after declaring it my problem went away. So.... maaaaaaaaaybe I happened to run across a global variable? Except... I don't do those. I honestly never really did track this down. Either I ran someone else's code unwittingly (very unlikely) or I ran into a bona-fide issue where the script parser was not properly isolating... um... I don't know the terminology here, but I think it was improperly containing it's scope.
Worse, this particular scripting layer on top of this particular app means a lot of functions return an array of floats or strings or whatever instead of just giving me the one thing I want. Imagine asking the script to find a specific object, but it gives you an array of them anyway. So you end up writing code like "Results = Find(Item); MyNewItem = Results[0]; ... all the time. You can probably type print(Results) in just about anywhere in my code and see something!!
Now since my faith was shaken that the variables I am using were freshly created for this function, I also include the type in my Results variable. So fResults is an array of floats, sResults is an array of strings, sResult is a single string, etc. I'm pretty sure what inspired me is related to your remark about using I to count in loops. I'm more of a generalist-scripter, I've worked on automating at least ten different apps in my life. So I've seen lotsa stuff from different corners of the web.
Welp one benefit of standardizing this way is I can easily copy and paste smaller bits of functions and not have to change the variable names. I mentioned the 'Results' thing for example, it might take me 3 or 4 lines to ask where an object is so that's kinda nice. Also I'm not re-typing variables... which I should have mentioned earlier could have been a culprit for my array-silliness.
I feel like by the time I'm done writing scripts I'll know how to do it.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 3, Interesting) by VLM on Tuesday November 19, @09:13PM (1 child)
Yeah I'm familiar with that, that was a "big deal" in the early 2000s or maybe late last century.
https://en.wikipedia.org/wiki/Hungarian_notation [wikipedia.org]
It's gone in and out of favor over the years...
(Score: 2) by Mykl on Tuesday November 19, @09:59PM
I always use it, but I go even further - I also include the scope of the variable if it is higher than the local procedure/event/function. For example, a global integer storing Foo would be declared as giFoo.
(Score: 2) by mhajicek on Tuesday November 19, @07:23PM (1 child)
You get to name your variables? Luxury! In FANUC MACRO B, variables are numbered.
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 3, Touché) by VLM on Tuesday November 19, @09:10PM
TRS-80 level 1 basic only has two strings A and B and one array A(). People think I'm making this up, but ...
Of course it ran on 4K of ram so that was impressive.
I "seriously used" a model 3 with level 2 and 16K of ram as my daily driver starting in 1981, although I had access to older stuff once it became cheap surplus so I am somewhat aware of level 1 basic's limitations.
Level 1 was so simplistic it didn't bother with a software keyboard debouncer, unfortunately not kidding.
(Score: 0) by Anonymous Coward on Tuesday November 19, @02:08PM
He's right. I've seen many examples myself over the years. When I have time I'll see if I can find some online. I seem to remember the CERN particle physics code being a prime example. It was C++ written in FORTRAN. I believe it was on github.
(Score: 3, Insightful) by HiThere on Tuesday November 19, @02:35PM (1 child)
Which Fortran? It makes a difference. If your comparisons are clumped into three categories (lt, eq, gt) you can call that Fortran, or you can call it assembler. If you use structures avoiding goto statements, that's another kind of Fortran. (1980's IIRC) Etc. And Fortran 90 or there abouts used classes. There's another kind of separation based on common blocks for globalish variables. At some times all global variables were in the same common block, a bit later there were named common blocks, so different routines had access to different blocks of them.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 5, Insightful) by Anonymous Coward on Tuesday November 19, @02:55PM
Your sig is particularly relevant. Javascript, (all things Java) is the ultimate cargo cult language
(Score: 1, Funny) by Anonymous Coward on Tuesday November 19, @02:25PM (4 children)
I mean, how can the kids understand computers without knowing basic electricity?
(Score: 2, Touché) by Anonymous Coward on Tuesday November 19, @05:57PM (3 children)
"how can the kids understand computers without knowing basic electricity?"
How can you drive a car if you don't know how electronic fuel injection or automatic transmissions work?
(Score: 2, Funny) by Anonymous Coward on Tuesday November 19, @06:34PM
Yes, we are burdened by too many layers of abstraction. If you can't program in assembly at least, (binary would be preferred), you can't be much of a programmer, and considering how horrible most drivers are, a basic course in physics, momentum, inertia, etc, and some mechanics should be a minimum requirement. We might see a little less tailgating on the freeways.
(Score: 2) by Freeman on Wednesday November 20, @02:39PM
Perhaps they drive an EV with a manual transmission?
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by PiMuNu on Thursday November 21, @09:24AM
Drive a manual
(Score: 3, Interesting) by brausch55 on Wednesday November 20, @03:13AM (1 child)
Hungarian notation as first used was good. Actual engineering units or descriptive text abbreviations for variable names. For example, pxVert and pxHoriz are good: intVert and intHoriz are not.
cmLeft and cmRight are good and not to be confused with inchTop and inchBottom. Having them all be floatLeft, floatRight, floatTop etc. is asking for trouble.
(Score: 2) by PiMuNu on Thursday November 21, @09:28AM
Although if you have units in your code (beyond UI) then you are doing it wrong.