Four Characters Saved the Project!
Have you ever tried to type with gloves on? Not on your mobile phone (which can be considered barely passable with the right gloves), but on a full size keyboard…?
During the frigidly cold ☃️ Winter of 1993-1994, the Epic building was not a warm cozy place in every office. The office I was sharing at the time could have doubled as a refrigerator. I didn’t need an ice-pack for my lunch as the room was cold enough. Space heaters were prohibited for two reasons: the Madison Fire Marshall did not approve and the building’s electrical was temperamental on many circuits. The building was likely wired during an era when the occupants had lamps, electric pencil sharpeners, and the Space Race hadn’t even been a dream. My teeth chattered along with the clacky keys of my keyboard. That is, they clacked when I could get my cold stiff finger joints to perform the basic operations. Desperate to warm my fingers, I’d wear my winter gloves, but that just resulted in even longer MUMPS routines that contained more gibberish than normal.
With an endless stream of glamorous possibilities for the Cohort Public Lab product, I was assigned an important project:
PRJ 249567: DELETE ALL BATCH TESTS RESULTS AFTER FAILURE
(I have no idea what the actual project number was. But did you know that Cohort and Foundations used the PRJ database before it was “cool” for other teams at Epic? And a big hat tip to any reader who knows where that number is from — hint: it’s a Hollywood reference.)
The Project
Occasionally, the lab would need to throw out a large batch of test results. Accidents happen. Machines fail. Zombies attack. Apparently, these incidents happened frequently enough that that the manual deletion of one-by-one-by-one was a terrible experience. It could be a dozen to hundreds of tests that needed to be voided/deleted from the system. The existing user interface was on Cohort Lab screen using Chronicles Screen Paint (a neat way to draw a screen, show data, and have input entry). Using the arrow keys to navigate patiently to the result to delete, press the appropriate function key, wait for it, and repeat. There’s no way to sugar coat how slow that process was. Screen refreshes were like like using a 2G mobile/cell signal to watch videos on Tik-Tok.
My task was to make this a noticeably faster operation. Naive me got to coding. As this logic was embedded inside of Cohort and in a particular screen as part of Chronicles, there were more than a handful of “rules” that had to be followed. Some rules were there to to prevent screen issues and others to prevent data corruption. I followed the rules. Screen glitches were annoying for users and data corruption would lead to an unhappy end and trouble down the road.
The first results SUCKED.
While the data was removed faster than a human could have performed the same operation, it was akin to upgrading from that 2G to a weak 3G mobile signal. There was a lot of buffering, screen painting, and a lot of frustrating waiting. I talked to my TL who suggested looking for other options but she had no specific advice. Following the rules and common patterns seemed to be the problem.
Undeterred by the rules of Chronicles and MUMPS, I sought a creative workaround. Interestingly, because of the way Screen Paint worked, the prescriptive process was to remove rows from the results one by one, which caused a repaint. The code removed row 1, then row 1, then row 1 … For common interactive workflows, the order in which this was done didn’t matter. Fast enough. In this case, the sheer volume of results caused the screen painting algorithm to be constantly busy and the terminal would only occasionally refresh meaningfully (the terminal was constantly busy).
Eureka!
During a moment of non-caffeinated free-soda-fueled inspiration I realized that disabling updates to the screen and deleting rows from the END of the list would significantly improve the performance of this workflow. Cohort’s lists were often uncommonly large compared to other Epic applications, so this wasn’t a pattern that was routinely necessary. Almost instantly, it was fast!
I immediately went to see the TL and mentioned now there was an interesting problem that cropped up — nothing happened visually on the screen until the list was nearly empty. The code was busy deleting and the screen wasn’t refreshing. There was nothing to watch for the user. It was just doing its $job.
Like a modern application where there’s no beach-ball or spinning hourglass, Cohort just seemed busted.
IT’S DEAD JUDY
I tried adding some warning text using standard mechanisms before the process started, but that wasn’t very effective:
DON’T PANIC. TRUST ME, I AM BUSY RIGHT NOW.`
That may not have been the exact phrase I tried, but the user experience was confusingly great and awful at the same time. We could have shipped it that way with a slight tweak to wording. I wanted a great user experience that didn’t leave the user in a state of elated befuddlement. It was fast! Hold on — when I say fast in this context … it was fast for 1993-1994. The operation even after this vast improvement was in the 30-60 SECOND range to remove many hundreds of voided test results. Yes, you read that right. 30-60 seconds! Compare this to the 15+ minutes that a customer would spend manually doing the operation and you can see why this would have been a phenomenal workflow improvement, especially as the task was tedious and the result of an unintended incident in the lab.
As you may recall during the creation of EAVIEWID, I had learned the hidden secrets of the terminal and how to bend it to my will through the power of terminal (control) codes. An idea formed … what if …
These four characters changed the world project: \ | / -
The Spinner is Revealed
At a few key workflow points during the long operation, my new code replaced the text at a specific location on the lower left of the screen with one of those characters. I know I didn’t use complicated logic to make sure that the pacing was even … it performed much like the Windows 95 till Windows vCurrent file copy dialog … via spurts of rapid progress and then sudden slow downs. Wasting routine characters and CPU cycles for an animation easing with 4 terminal characters was out of scope no matter how much I would have wanted to add those even back then (there was no sub-second precision timer available either in MUMPS then, so…).
But, in the end, the new functionality and simple animation worked well and customers rejoiced partied after receiving and using the new functionality.
I don’t remember if the Cohort team and other coworkers gave me high-fives for my creative solution, but I don’t remember them NOT doing that either. 😁
Brr ❄️🧤 Brr
Thankfully, I was able to complete the project without my winter gloves. While I have a few fond memories of the Epic Medical Circle building experience, I am glad I only spent one cold Winter season at that location.