The Best (and Worst) Code I Ever Wrote

As a software engineer, I've written a lot of code through the years and forgotten most of it. Some bits, though, I remember vividly. One routine in particular sticks out in my mind as simultaneously the best and worst code I've ever written.

Picture this: we have a set of official forms used in nursing homes that need a UI to set the configuration for each form. There are three types: Physician Order (A), Medical Administration Record (M), and Psychotropic (P). For reasons I can no longer remember, there were two categories: the first had only Physician Order and MAR forms, the second had all three. With me so far?

Herein lies a cautionary tale against the "it's just..." reasoning. The request probably sounds simple so far. It's decently easy to explain and understand. However, because of the complexities around that functionality, I wrote a routine that persisted in that code for probably a decade or more until the project was officially deprecated and shut down.

The first complication was that not all facilities used all available forms. We didn't want a bunch of configuration options for forms they didn't even use, or potentially didn't even have the programs to run. In fact, if you tried to open the settings for a form you didn't have installed, it would crash the software. We needed to filter the options page to just forms that were available on the specific customer's system.

The second complication was that we didn't have an explicit list of installed forms. The only way that we could tell what forms the customer had was by looking at the list of installed programs (everything from menus and business logic to those form options) and look for programs that followed a certain naming pattern. From memory, it was something like P8(A/M/P)##A. For example, P8M87A was the program for MAR form 87.

With that list of programs, I used something like the IBM Series/1 Assembler equivalent of a regular expression to pull in everything that looked like a nursing home form. Occasionally, someone would create a new program that accidentally matched the filter as I wrote it. When this happened, it would give a new form option that users would click out of curiosity and crash the system. I would have to create a fix that explicitly ignored that particular program in an if statement.

Fortunately, the program list did keep the forms within their respective categories. The exact order would always be Physician Order, MAR, Physician Order, MAR, Psychotropic (if it existed). Because of this guarantee, we could assume a few things about the list as we iterated over it:

1. From the beginning, if the item was a Physician Order, it belonged to the first category.

2. After you encountered a MAR form, you were still in the first category, but you would never see another Physician Order form from the first category.

3. The next Physician Order program would begin the second category.

4. MAR at this point would exclusively belong in the second category.

5. You may potentially find items after the MAR programs. These were always Psychotropic forms in the second category.

Now, in modern architectures, this would probably be the end of the headache. UI platforms and libraries tend to handle a lot of the heavy lifting and allow you to pass data around pretty elegantly. However, this was Visual Basic 6. We didn't have any of that.

To tell you about VB6, it was very picky with how screens were composed and how it handled data. You needed to know the sizes of arrays and lists when you created them. Beyond that, getting UI elements to work the way you expected was nearly impossible. Writing in assembler language always sounded like it should have been the worst part of my job, but VB6 was worse.

So at the point where we wanted to print these form links on the screen, we simply had a list of programs with an unknown number of A, M, A, M, P forms in that order. We could infer categories based on the order, but because of the difficulty of passing data around in both Series/1 and VB6, it was hard to apply additional information in a way that could be easily accessible.

This is where my beautiful, awful, legendary code lived. I started with a few iterators and booleans in a for loop. The routine iterated over the list of programs, incrementing one of the iterators each time and looking for a MAR form. When it found the first MAR, it set the size of the Physician Order array for the first category to the value in that iterator. It also set one of the booleans to indicate that we were finished with the first round of Physician Order forms.

Within the for loop, a nested if statement checked if we were finished with the first set of Physician Order forms. It then started checking for something besides MAR forms. After we found the first item that wasn't a MAR, we knew that we were in the second category and should be counting Physician Order forms again. Guess what; another boolean and another nested layer of if statements.

All in all, the routine took probably 3 layers of if statements nested within the for loop. Could it have been more optimized? In a modern system, sure. In VB6 and Series/1? Maybe, but probably not.

The team had the policy that if you touched something, you owned it. It was made abundantly clear that if anyone ever messed with that code, it was theirs. Because of the complexity, and the inability to get around it, nobody ever changed it.

I wish I could go back and see the original code. I've done a lot of inventive things through my career, but that one sticks out to me the most. As far as I know, nobody was ever able to improve that routine, and my code lived in the repo until that product died entirely. I take pride in creating that monster, but also a little shame in how clunky it was.