Jay Little
logo
Spock Was Wrong: In Tech it is Easier to Create than to Destroy

04/05/2021 20:17:48

I assume most of you didn't already know this, so I'm going to clarify it up front. One of my favorite sci-fi trilogies is comprised of Star Trek II: The Wrath of Khan, Star Trek III: The Search for Spock and Star Trek IV: The Voyage Home. Obviously they weren't meant to stand alone as a trilogy as they are three movies plucked out of a larger group of films, but I don't care. They share a coherent story arc between them which begins with the second film and is resolved at the end of the fourth film. There are parts of these movies that inspire much debate among Trekkies, but as a whole, short of a few exceptions like the Matrix trilogy, they are my favorites.

One of my favorite parts of the movies is a scene in Star Trek II where Kirk, McCoy and Spock are discussing the Genesis Device after watching an introductory video on it. For those of you not in the know, the Genesis device was a missile that was capable of bringing life to an otherwise lifeless planetoid. It effectively represents the transcedence of human beings from inhabitants of the universe to masters of it. The trilogy of course revolves around how wrong and short sighted this belief is and explores that theme in quite a bit of depth and from a variety of angles. In any event after watching that video, the following exchange ensues between Spock and McCoy:

McCoy: But, dear Lord, do you think we're intelligent enough to... Suppose, what if this thing were used where life already exists?

Spock: It would destroy such life in favour of its new matrix.

McCoy: It's new matrix? ...Do you have you any idea what you're saying?

Spock: I was not attempting to evaluate its moral implications, Doctor. As a matter of cosmic history, it has always been easier to destroy than to create.

Spocks final sentence has always struck me as rather poignant and I've carried it with me over the years as a reminder. But as a reminder of what? I honestly do not know. As of late, I have spent a lot of time thinking about the reverse trend in technology in which nothing ever seems to really die or go away. In fact if you take a hard, honest and broad look at tech in general, what you'll see very much resembles the diagrams we were shown of the fossil records in school. Only in this case those dinosaurs didn't die off, they just got buried by the new stuff.

Tech is much like that. We all talk about cutting edge web stuff and mobile tech, while overtly ignoring the army of older tech still in service which is dutifully performing some duty or another. Virtually nobody is learning COBOL in school now, yet it drives a wide variety of systems that society and corporations rely upon. When I was getting my associate degree in the late 90s, I actually took two semesters of COBOL as part of that program and I hated every minute of it. It was an obtuse, wordy and limiting language. Yet they were teaching it because local employers were hiring COBOL programmers straight out of school. I also spent a semester with RPG which is far less prevalent than COBOL yet it still persists as well.

A year ago I ported an old FORTRAN program for my employer into ASP.NET Core C# and even though my ability to read FORTRAN is terrible, I managed to get the job done by spending a lot of time reading documentation. Despite the terrible nature of the code and the brittle nature of the data structures it contained, I came away impressed by FORTRANs ability to process and perform mathmatical operations against wide swaths of data contained within arrays in a very simple and concise fashion. This isn't something that we value in modern languages as we generally don't spend a lot of time working with basic arrays. Nevertheless I acquired some appreciation for some of the unique things FORTRAN brought to the table. In any event, I completed a line by line port of the program which not only replicates the results of the original program but it also fixes some of the overflow related bugs present in the original version. It is worth noting that while Python is generally considered to be the heir apparent to FORTRAN, I find this to be comical as Python's track record with math is less than great and as a language it leaves a lot to be desired.

Now don't get me wrong, I am in no way advocating that we romanticize this older tech. In fact I want to be really clear: I despise the majority of it. But I don't hate it because it's old. Far from it. In fact I actually love the idea that those coders from 20 or 30 years back wrote code that managed to stay in service for so long. The older I get, the more that kind of superficial longevity tends to appeal to me so you'll have to forgive me. But no the reason I despise them is because this tech is thoroughly unprepared for the world in which it now operates. People who wrote these pieces of code didn't have to think about things like buffer overflows, server-side versus client-side validation, weak encryption, malformed packets or a wide variety of other maladies which have since emerged as threats in the modern world of tech and software.

Of course when pressed the users of this tech will tell you that none of these concerns are valid as they aren't connecting any of this stuff directly to the Internet. But even so at this stage of the game, the lack of a direct internet connection isn't the Holy Grail so many want to believe it is. If the code is operating on a network that has the ability to receive or send traffic to the internet in any way, shape or form, it is at risk. Even if the network itself is actually air gapped the truth of the matter is that your users are likely still your weakest link and tech they are using to interact with yours can and likely is being attacked.

But companies and individuals around the world still persist on sticking with fossilized tech. In terms of Operating Systems and Office Suites, they still run Windows XP, Windows Vista, Windows 7, Office 97, Office 2003, MS-DOS, Novell Netware, OS/2 Warp (seriously, some ATMs still run it to this day) and even age old versions of Unix / Linux. I have clients who stick with severely outdated ERP systems and entirely custom web systems which are basically not being maintained or updated at all. When you try to address the point with them, the conversation inevitably drifts to the fact that they spent oh so much money on this tech stack and how they intend to recoup possible penny of return on their investment.

It seems to me that we all seem prone to falling into the trap of becoming too attached to our tech. Whether its your sacrosanct workflow that you are unwilling to modify or the fossilized tools you are using to power it, the consequence is the same: You are drifting closer to becoming overtly inflexible and thus irrelevant. This is something we all face as we grow older I think. For me it has largely manifested in my unnatural love for retro gaming from the 80s and the 90s. But for the most part, there is very little to no risk associated with playing old games. Thanks to emulation most of that code runs in a sandbox by default and most of that code was written well before the sandbox even existed, so your chances of that dependence being exploited are exceptionally low.

Nevertheless, it is important to note that just because something is new, that doesn't make it better. There are numerous examples of this trend at work and I have spent quite a bit of time touching on that trend on this very blog, so I won't bore you with the details. Nevertheless it is worth mentioning. It is equally important to re-emphasize that older techs like COBOL aren't bad because they are old. Their age has little to do with it. Techs like COBOL are bad because they were created to address the needs of a world that is very different from the one we are living in today. To honestly believe that COBOL code written 30 years ago is still capable of fully addressing modern needs, means you are basically shoving your head into the sand and ignoring decades of recent history: The Good, the Bad and the Ugly.

I would personally like to see more tech die, especially in situations where any kind of network is involved. The world we live in now is very connected and by extension exceptionally dangerous. Techs like COBOL just aren't capable of meeting the needs created by such large and dynamically evolving challenges like the ones we are facing today. On the flip side, I'd also like to see more modern tech be summarily rejected for being a waste of everybody's time. All too often we as techies are quick to embrace something with open arms just because it's new without seriously considering whether or not its actually better.

Somewhere in between these two extremes lies sanity and safety. I'd love to see us make our way to that place sooner rather later. Together we can build a better world, but that also means we shouldn't mindlessly toss away the new for the old or the old for the new.

Search:
[Top] [Rss] [Email]