This one's going to be a tiny bit weird. Yes, it's a listicle. Yes, the title is a bit clickbaity. No, it's not a tutorial. Yes, there will be some new tutorials coming up soonish, I'm working on something biiig. Yes, I learned tons of things. Yes, I will stop answering questions now. Bear with me for this one, as I will tell the tales of stub articles and obscure metaphors found in the unthinkable depths of the rabbit hole Wikipedia can be.

I recently started watched a video on cargo cults and thought that I must've heard that term some time ago, but in a different context: Cargo cult programming. I didn't exactly know what it meant, so I stopped the video half-way, fired up A Popular Search Engine™ and Popular-search-engined™ the term and to be honest, I got carried away. Lots of "What on earth"s and "Huh"s later, I would like to share this list of 25 terms, most at least I haven't heard of - with around 10 years of experience in the industry, mind you!

Disclaimer: Some of these terms are not exactly nice, some might even be offensive. This article is meant purely as a "scientific" piece to educate on the existence of them, not endorsing them in any way.

So, let's get into it.

1. Cargo cult programming

https://en.wikipedia.org/wiki/Cargo_cult_programming

The start of my Wikipedia-journey. Cargo cults are most of the time religious constructs. Believers of cargo cults often once witnessed a more advanced civilization and saw that what they did on the ground, like military parades, building air fields, made cargo, often food, medicine and the like, appear from the skies or seas. The believers interpret the happenings as rituals and mimic them in the hopes to also make those goods appear.

Cargo cult programming describes a similar behaviour. It means copying and pasting random bits and pieces of code from other, often similar programs, not understanding what they do, hoping they make the software work.

2. Copy-and-paste programming

https://en.wikipedia.org/wiki/Copy-and-paste_programming

The name sounds related to cargo cult programming, right? Almost. Instead of copying other people's code, how about copying your own for a change?

Copy-and-paste programming means copying the same functionality over and over. Sometimes it's necessary because the language lacks abstraction mechanisms, sometimes the author simply doesn't know about them.

3. Shotgun debugging

https://en.wikipedia.org/wiki/Shotgun_debugging

This is not about a jam in a musket. Shotgun debugging is the "art" of changing random parts of a code base in the hopes of solving a bug. Just like a shotgun shell, shotgun debugging punctures various places at once without much visible structure.

The success of shotgun debugging is often limited, but when it's combined with deep knowledge about the code base, it might even be faster at times.

4. Shotgun surgery

https://en.wikipedia.org/wiki/Shotgun_surgery

Another, arguably more gruesome gun metaphor. Most of us have seen it happen, some of us even had to do it.

Shotgun surgery refers to changes in one code piece that need several small changes in other places. Ever added a new mandatory parameter to a function that's used all over the place and then had to adjust every single function call? That's a shotgun surgery.

5. Voodoo programming

https://en.wikipedia.org/wiki/Voodoo_programming

That one also uses a metaphor related to religious practices. Voodoo programming is related to Cargo cult programming. In fact, Cargo cult programming and Voodoo programming are so similar, that they might as well be synonyms.

But the difference lies in the problem: Voodoo programming implies that the problem isn't understood. Trial and error, as well as copy/paste from Stackoverflow and/or other projects are also used in Voodoo programming, though.

6. Deep magic

https://en.wikipedia.org/wiki/Magic_(programming)#Variants

Let's keep the mystic theme for a bit longer. The term "magic" is known in coding culture. Often "magic" means hidden complexity behind a simple interface. For the beholder, the complexity might as well be magic.

Deep Magic refers to some arcane knowledge, though. Just like a magician, some companies never tell their secrets. Deep Magic refers to not widely-known techniques and practices that are sometimes even deliberately kept secret - for whatever reason.

7. Yoda conditions

https://en.wikipedia.org/wiki/Yoda_conditions

Widely used, Yoda conditions are. A popular framework that uses them, Symfony is. Accidental assignment, they prevent. They look like this:

if (42 === someNumber) {}

The name stems from one of Star Wars' most known and beloved characters: Grand Master of the Jedi Order Yoda. For those who haven't seen Star Wars, Yoda is a wise, old, green being that talks in a somewhat reversed syntax. Since conditions usually follow the form of someNumber === 42, reversing the variable and the number resembles the way Yoda talks.

8. Big ball of mud

https://en.wikipedia.org/wiki/Big_ball_of_mud

This is one of my favorites. A big ball of mud is a piece of software without perceiveable architecture. That doesn't mean there's no architecture at all, though.

Big balls of mud are rather common, especially in old products that have evolved over time or that have been rushed. Increasing complexity and little time to refactor favor big balls of mud.

9. Spaghetti code

https://en.wikipedia.org/wiki/Spaghetti_code

A true classic. I'm almost certain, that most devs have heard that term. It's the reason I chose the yummy cover image and added a spaghetti emoji to the title.

For those who don't know what Spaghetti code is: You most certainly encountered it at least once in your career. Spaghetti code looks like a pile of spaghetti. According to Wikipedia, Spaghetti code uses little to no programming style rules and is mostly created by inexperienced software engineers.

Possible variations of the term include ravioli code and lasagna code. Ravioli code refers to well-structured classes that are simple to understand in isolation, but not as a whole, whereas lasagna code describes an architecture of non-separated layers that are so complex, that a simple change in one layer would cause a change in all other layers, resulting in shotgun surgery. See? We already learned something!

10. Magic pushbutton

https://en.wikipedia.org/wiki/Magic_pushbutton

The magic pushbutton is related to UI design. It describes a single button that triggers a lot of business logic under the hood, coupling the user interface to the business logic at a single point. Think of it like the body of a wasp: Where two segments of the body meet, that's where you find a magic pushbutton. Almost like the pot of gold, but not as exciting.

From a user's perspective, all inputs need to happen before the push of the button, all business logic must happen after the push. This gives the user the feeling of the app being clumsy and the button itself being frustrating to use. Think of a huge form with several dozens of fields. You spend hours entering everything, click on submit, wait a few more hours until the backend responds only to get an error message. I know right?

One way to mitigate that is to execute business logic as early as possible, for example with frontend validation.

11. Yo-yo problem

https://en.wikipedia.org/wiki/Yo-yo_problem

Another anti-pattern. There's a lot of anti-patterns on this list.

The yo-yo in the yo-yo problem is figuratively describing a developer going up and down a dependency graph just to understand what is going on. This happens with large inheritance graphs or deeply nested dependencies (I'm looking at you, Node!) that are so complex, that you constantly have to go back and forth in order to keep track of what's actually going on.

Especially in OOP, the yo-yo problem can be mitigated by building flat hierarchies, which is encouraged by a lot of books on design patterns.

12. Boat anchor

https://en.wikipedia.org/wiki/Boat_anchor_(metaphor)

Another one of my favorites. A boat anchor is a piece of technology whose only productive use is to throw it over board. Most of the time this is completely obsolete and useless technology.

When used in software development, a boat anchor means a piece of code that is left in the code base, because people often don't know if it's every going to be used (that's what we have Git for, right?) or if it was even useful to begin with. I reckon that most boat anchors are the results of either voodoo programming or cargo cult programming.

13. Action at a distance

https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)

I think this one's related to Einstein's famous description of quantum entanglement. Einstein didn't like the idea of particles being "linked" together, causing a change on one particle to be immediately propagated to the other one, no matter how far apart they are. He called it "spooky action at a distance."

In software engineering, action at a distance means the effect of a piece of code behaving wildly different because of some change of parameters in some seemingly unrelated piece of code somewhere else. In my opinion, this has a lot to do with global state (I'm looking at you, 2000s PHP with your global $foo; everywhere!) and can be mitigated by clear architecture and well-used design patterns.

14. Data clump

https://en.wikipedia.org/wiki/Data_clump

A data clump describes a bunch of inseparable friends that go everywhere together. Only that those friends are variables and the "everywhere" isn't exactly the mall or the park, but other parts of the code.

A good exmaple (also taken from Wikipedia) is coordinates. If you always need to pass around separate variables X, Y and Z, but never ever use them standalone, you've got a data clump that should ideally be a value object called Coordinates.

15. Software rot

https://en.wikipedia.org/wiki/Software_rot

Ever worked on a legacy project? Had to refactor a function that was written in what felt like the 1600s? Exhausting, isn't it? Well, at some point, someone deemed the piece of code you're working on now as state-of-the-art. They liked their work.

Software rot describes what happened in between some dev creating the piece of code and some other trying to work on it years later. The software became hard to maintain, is screaming for an update or is downright useless. The software has rotten.

In order to mitigate software rot, software needs care frequently. Update those dependencies, update the language level as soon as another LTS version is released, update the software if its surroundings have changed.

16. Fat comma

https://en.wikipedia.org/wiki/Fat_comma

Also known as a "fat arrow." Depending on the language you're using, the fat comma can occur in various different places. Usually it is used where normally a comma would appear, but is still valid syntax. Think of PHP here. Arrays are usually initialized like this:

$arr = [1, 2, 3];

The fat comma would come in as soon as you use a key. It transforms the otherwise valid array item into a key and uses whatever comes after the fat comma as the actual value:

$arr = [1, 2, 'foo' => 'bar', 3];
// Fat comma here---^

Why this would be called a fat comma? I don't know. Perhaps this term is used in language design.

17. Comment programming

https://en.wikipedia.org/wiki/Comment_programming

This is related to the boat anchor, but is made on purpose. Comment programming, or Comment Driven Development (CDD), is the practice of commenting out code in order for it to not be executed. Wikipedia states that comments are used to describe things, but are often used to simply "turn off" pieces of code. The term itself is often meant derogatory.

I've just witnessed CDD in a project: Instead of removing some debugging setup, the entire code block was commented out, so it would save time, should one wish to use said debug setup. Even though it's technically an anti-pattern, it can be useful.

18. Conference room pilot

https://en.wikipedia.org/wiki/Conference_room_pilot

A conference room pilot is not the boss steering the conversation in the conference room. A conference room pilot is a specific role used in software acceptance testing. The pilot usually validates the software product against the business processes of the end users.

They allow end users to test the product with typical business processes they have in order to see how useful the software actually is.

19. Fill character

https://en.wikipedia.org/wiki/Fill_character

A fill character is a character (as in: letter in some alphabet like unicode or ASCII) that is solely used to consume time. Yes, to consume valuable, precious time. Old printers use these a lot. Wikipedia has the example of an old mechanical printer that prints 30 characters per second. So the machine sending the document naturally sends 30 characters per second. But: A carriage return takes a few seconds and the old printer has no way of keeping the received characters anywhere and has no way to tell the sender to stop, so the sender just sends "fill characters" after a carriage return to pass the time until the printer is ready to receive actual characters again.

I reckon this practice was also probably used in the old days of networking to prevent race conditions, who knows.

20. Worse is... better?

https://en.wikipedia.org/wiki/Worse_is_better

Yes, worse can indeed be better. Sometimes. The phrase compares functionality/features with software quality and was originally coined by Richard P. Gabriel.

In a nutshell, adding more features can make the quality of the software go down. See Big ball of mud. More often than not "worse" (for the user, i.e. less features) is "better" for the software quality.

"Worse is better" is also referred to as the "New Jersey style" is a complete software engineering model that propagates four different key aspects:

• Simplicity of the design of the code and the interface
• Correctness of everything
• Consistency of the design
• Completeness, as in everything important should be covered

21. Deutsch limit

https://en.wikipedia.org/wiki/Deutsch_limit

What some people experience when they speak German as their second language, but don't understand everything. Just kidding, of course it's not that.

The Deutsch limit has its name from Peter L. Deutsch. It's only used for so-called "visual programming languages", such as Blender's internals, LabVIEW, or parts of Unity. The Deutsch limit says that, especially in older languages, there cannot be more than 50 primitives visible at any given time. This is often used as an example how text-based programming languages are "better", because they offer more information density on the screen.

22. Greenpun's tenth rule

https://en.wikipedia.org/wiki/Greenspun's_tenth_rule

Quote:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

That means that any complex program will at some point implement half of Common Lisp's functionality. This is related to the so-called "inner platform effect", where, in order to cover as many business cases as possible in a given program that runs on a platform, you essentially build your own platform within the existing platform.

By the way, there's no nine other rules, they just wanted to give it a memorable name.

23. Software Peter principle

https://en.wikipedia.org/wiki/Software_Peter_principle

The Software Peter principle describes a "dying project" that has gotten so complex that not even the developers of the code themselves understand it anymore. According to Wikipedia, it is "well known in the industry" and I'm pretty sure certain frameworks, operating systems or even email clients have become Software Peters.

The name comes from the "Peter principle". This principal states that a person called "Peter" will rise through the hierarchy of an organization by having success in their current position, until they've reached a position they are incompetent in. Translated to software, the "dying project" is Peter.

24. Heisenbug

https://en.wikipedia.org/wiki/Heisenbug

Stemming from the name of Werner Heisenberg, a famous physicist that worked on quantum physics, the Heisenbug is one of the nastiest things you can encounter. Werner Heisenberg asserted that, by observing a system, for example by measuring things in it, you always influence and therefore alter the system.

A Heisenbug is exactly that: By investigating the bug, it starts to change its behaviour. I reckon this is often caused by race conditions and the like.

The opposite of a Heisenbug is a Bohrbug. Nils Bohr came up with the deterministic atom model we all know and love. A Bohrbug describes a "good and solid" bug.

25. Bogosort

https://en.wikipedia.org/wiki/Bogosort

This one I actually already knew. And apparently I couldn't do a post without at least a tiny bit of a tutorial in it.

The Bogosort algorithm is arguably the most hilariously inefficient and downright simple sorting algorithm there is. It shuffles the elements of a list until they're sorted. That's it. Here's a quick implementation in JS:

const isSorted = arr => arr.reduce(
  (prevVal, currVal, currIndex, arr) => {
    if (currIndex === 0) {
      return prevVal
    }

    return prevVal && currVal >= arr[currIndex - 1]
  }, true
)

const bogoSort = arr => {
  let numberOfIterations = 0
  while (!isSorted(arr)) {
    numberOfIterations++
    arr.sort(() => Math.random() - 0.5)
  }

  console.log('Total iterations: ' + numberOfIterations, arr)

  return arr
}

bogoSort([2, 1, 3, 4, 6, 12])
// Total iterations: 2785 [ 1, 2, 3, 4, 6, 12 ]

My tests yielded somewhere between 3 and 3000 iterations, but theoretically, they could go on forever. Each shuffle is an independant dice roll, so the chances of the list being sorted don't go up over time. Quite inpredictable! Please don't copy-and-paste this in an attempt to figure out what Cargo-cult programming is like.

Phew, what a journey. A fun one, surely, but also a weird one. I'm going back to coding now.

I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️ or a 🦄! I write tech articles in my free time and like to drink coffee every once in a while.

If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!