A Guide to Bad Code

Hello World!

This week, I want to dive into a common issue that's hard to ignore: the abundance of bad code. I'm not just talking about messy code, but code that's often designed outside the software engineering realm by folks who care little about code quality and make do with inadequate tools. I've been thinking about this topic a lot lately because I had two close encounters with some very questionable code: OneLoop structured text and the Yolo County voting machines.

The Structured Text Language

I'm currently a programmer for the UC Davis HyperLoop team. We take part in SpaceX's annual HyperLoop competition, where teams from around the globe race to create the fastest pod. These pods race through a vacuum tube built by The Boring Company in Hawthorne, and the fasest wins. I recently applied for a leadership position, but regardless of the outcome, I plan to stick around as a programmer for the team next year.

There has been one major issue with me working as a programmer on this team though, and that is the fact that HyperLoop is primarily a mechanical engineering project. This means that most of the members, despite being talented mechanical engineers, don't loose too much sleep over code quality. As one of them said to me recently, "to a mechanical engineer, programming is a tool, to a programmer, programming is an art".

Just to be clear, I'm not saying this is inherently a bad thing. At the end of the day, we all just want to get our work done and do well in the competition. If that means resorting to quick-and-dirty code, so be it. But it can be a tad frustrating for me. For instance, the programming language was chosen solely based on what the propulsion team preferred. We have a sponsorship from Rockwell , providing us with top-notch controls technology. A Rockwell controls system is like a significantly more professional version of an arduino — a grown-up arduino if you will. This means that I need to use Structured Text programming. The fact that it is essentially impossible to coerce Structured Text into anything I would consider "good code" is somewhat irrelevant.

In factories, folks often use what they call "ladder diagrams," designed to look like a 'relay rack' used for designing machines that make industrial products. I suppose if you're used to reading ladder diagrams, Structured Text might make sense, but it's far from intuitive for me.

I've faced all sorts of problems just trying to get the integrated development environment (IDE) to run. It's Windows-only and demands specific libraries, among other headaches. But one of the most maddening aspects is the inability to simply command a function to run at regular intervals. Instead, you have to work within the IDE itself, tweaking settings instead of editing a file. There's no settings file to modify, so you're essentially creating a compiled binary file only readable by the Structured Text IDE. This means that if you want to share it on GitHub, you can only upload the compiled Structured Text file. This means uploading a very large file to GitHub, and it isn't even a file that others can read unless they have the Structured Text IDE downloaded on their computer!

The biggest hurdle for me in crafting good code in this language is that you can't define variables in your code; you have to define them in a sprawling spreadsheet. When you're dealing with about 50 variables, it quickly becomes a chaotic mess. There's really no reason for this approach, but I suppose it's a nod to how ladder diagrams work, and that's what Rockwell decided to use. As you can imagine, the program I've written doesn't come close to what any reasonable programmer would ever consider "good code."

But, that's not to say we should toss Rockwell out the window in this scenario. The truth is, when you're working on the HyperLoop project, creating impeccable code is never going to be the top priority. It's fundamentally a mechanical engineering project, and Rockwell makes sense for the propulsion system. So, it's okay to use what I might label 'less-than-optimal code' as long as it gets the job done. If a modern engineer scrutinized the code from the Apollo 8 launch, they'd probably be horrified, but it undeniably did what was needed. Sometimes, code is not art, it is just a tool.

Yolo county voting machines

On the flip side, there are times when we absolutely should have excellent code, but unfortunately, we don't. A case in point: the Yolo County voting machines. I'm currently part of a team led by Professor Bishop, and we're delving into these voting machines. I can't get into too much detail here because sharing voting machine vulnerabilities on the internet is a bad idea. However, there's simply no excuse for not developing more secure voting software. It's alarming when our voting security software falls short of the security standards we demand for video games. So, while there might be situations where less-than-ideal code is okay, I'd argue that those situations are few and far between.

May you be ever victorious in your endeavors!
M.E.W