Escape Characters

Cargo Cults

I first learned about the term "cargo cults" from a software engineering anti-pattern of the same name.

The term comes from the phenomenon that occurred around and during WWII, when tribal cultures with limited or no contact with the Western world suddenly came into contact with the military machines of various warring nations. Seeing soldiers, weapons, ships, planes, etc. for the first time, the cultures attempted to incorporate what they witnessed in terms of their religious and ritualistic practices. Believed blessed or otherwise considered by their gods, they mimicked what they saw of the military practices, including building runways, fake radios, weapons, and other things to bring back the supplies and material brought in from the military forces. Mimicking these structures and items, they believed they could call the gods back.

I might be explaining that poorly, but in terms of computer programming, the term is used to describe when a piece of code or development practice is put into place by mimicking something previous, but doing so does not yield the same result. For example, a company wants to replicate their working web portal login code to another project. They decide to simply copy the code from the first project into the second. However, when the second program is ran, nothing happens: no login page, no password validation, nothing. Despite taking what seems to be the exact same action, the second program failed to accurately identify what caused the login page to work.

(I use this example because for every application I've developed, I've ran into this exact same problem. And to date, I've developed a hell of a lot of login systems.)

The term is used less to condemn the practice of code reuse, and more to speak towards the implementation of certain things without understand the reasoning behind them aside from "It's what we have done before" or "It's what these people do." The idea is to justify the pieces and parts of a project, to analyze them, and to understand them for what they are and how they work, and not to just mimic something else.

I was thinking about this today. Talking at lunch, I brought up old video games, as I tend to do. I mentioned that since I was young, I was always the "computer guy," such that whenever we tried to play multiplayer games (Quake, Diablo, Battlezone, Starcraft) between my family's computers, I was the one responsible for having to figure out how to set them up, get them working, and ultimately, fix the problems if something went awry. And being older computers, running on questionable software, on questionable hardware pieced together over years of accumulation, things did go wrong.

Thinking on it though, I wasn't much of a "computer guy" back then. 10-15 years later, I can tell you that I was definitely guilty of simply mimicking troubleshooting practices I'd seen my father perform. I knew how to "ping" a device, but not what it was actually doing when I entered the command. I just knew that if the "ping" program didn't return something that looked familiar, something was wrong. Another example: early computer games had much more complicated ways to accomplish a multiplayer session. You had your choice of IPX (if you wanted to play on your local network), modem line (if you wanted to dial somebody), serial cable (if you were right next to somebody), and last but not least, TCP/IP (what everything is based on today). What I knew about these various networking mediums and protocols was that if one didn't work, I should try the next one. If one asked for an address, I should try to get the address. If I didn't know how to get the address, I'd get my father to help.

Granted, these might be concepts that are difficult for a 13 year old to understand, and so maybe younger Josh can be forgiven. After all, if your friends are over to play video games, neither you nor they want to be concerned with network topology, firewalls, or Ethernet duplexing, everyone just wants to play a game, and play we did. That's what kids do. The point is, though, the cargo cult pattern of computer troubleshooting continued, despite my total misunderstanding. I could potentially "fix" a thing, but not truly understand how or why. Once a problem goes away, it no longer really requires further analysis. And without this requirement for further understanding, it's a short logical step to say that, having fixed the problem, that I understand it.

This pattern of misunderstanding is extremely harmful to a "computer guy." In an industry where knowledge is the only true specie, misinformation is pervasive, poisonous and viral, and absolute truth is hard to come by. For instance, years later, I got my first job working as an "Internet Intern." This meant that I was building web applications for people. I'd been interested for a year or two in making webpages (this being in the middle of the Dot-Com boom), and somehow got a job making an Active Server Page web application with a database backend and a web-based user interface.

This was the worst thing I could have been doing. I knew barely enough HTML to be dangerous, and knew exactly nothing about database design, querying, or how I should be talking to the database from a web application to begin with. And yet, I was sitting in my little corner of an office, toiling away, copying from Google what seemed like relevant code into my application and hoping that it would work.

I learned a little bit, mostly from the instruction and tutoring of some of my nicer coworkers. However, my end product was complete shit. I can only hope they wiped the server I was working on completely after I left. The application was more of a liability to them than was the waste of my paychecks over the course of the summer.

The pattern followed me to my next job. I didn't know anything about doing IT tech support, other than the brief "fixing Starcraft" sessions I'd had some years before. But now, I was helping an entire engineering firm keep their computers running. And the next job. Prototype logistics programs. Military operation engineering manhour estimation tools. Why, oh why, did they have the intern working on their reporting engine, where the numbers actually had to mean something?

I guess a lot of crazy stuff was going on at those jobs at the time. And at the same time, they did have me hired as intern positions: I was expected to be there in a learning capacity, not necessarily to be their top coder.

The thing is: once I had completed a certain project, or task, or program, I had a feeling of great understanding, of having conquered something. Of having what was a problem no longer be a problem, and thus, warrant no further analysis. I understood everything.

The problem I'm having, thinking back on all this stuff, is I have the same feeling now. In fact, it's sort of what gives me some satisfaction at my job, knowing that I've been able to solve something using wisdom and wit. Granted, the things I do now are vastly more complicated and intricate than figuring out why somebody's computer stopped playing a game, but the fact remains that my brain has in it burned what can only be interpreted as absolute truths. Which, despite knowing the path it took to get to those truths, are no less potentially fallible than my cargo cult beginnings.

I can speak at length on all I know about computers, and all I didn't used to know, and how it's all been a crazy journey, etc., etc. If I continue to do so, you will get bored extremely quickly, and stop reading. So I guess I'll get to my final point.

What started bothering me, as I pondered this further, was that this great buzzing tree of computer knowledge happened to be the largest tree in the forest. And that smaller trees, ones consisting of realms of knowledge outside my professional expertise or personal interest, are those much akin to my early days working with computers, in that even if a branch arrives at a conclusion, there is almost no rational basis to how I reached that conclusion, only borrowed logic and mimicry.

I think about things I do in my adult life. I pay my bills. I pay my taxes. I get the oil changed in my car. I mow the lawn. I paint my house. Things I do because they seem like the prudent thing to do, but for the most part, I'm really going through the motions.

I think about things I'm usually wrong about. Electricity. How the screen on my phone works. Music. Women. People. Relationships. Things that continue to defy my every effort to establish truth.

I think about things I detest. Dancing. Football. Anger. Violence. Things for which I can only increase my distance from them, but can never abolish.

It's taken me 10 years to learn what I've learned about computers. I don't have the lifespan to do everything else. I might be able to learn five, maybe six things as well. But after time, my knowledge in what I've left behind for further pursuits will decay, not only with simply forgetting the grittiest of details, but the nature of old age.

I don't have the time or the permanence of memory to die in a forest. I will die in chaparral.

I can't not seek understanding of things. It's in my nature. I am curious. Analytical. "Detail oriented," some might say. But I can't in good conscience say that I understand something. Just that I sound like I know what I'm talking about, and to be willing to entertain conflicting ideas when they come along. Happiness, in this case, isn't reaching a potentially fallible understanding, but reaching a further understanding. Movement, but not position.

I can only hope everyone else is a cargo cultist as well.