I Wanted a New Job After This Project

Have you worked on a project that you really never completely understood? A project where you worked on it and completed it and couldn’t have answered many specifics about what it really did or was? Often, these projects take you out of your comfort zone but eventually the core begins to click and it starts to become something that clicks. That wasn’t the case in this instance.

I don’t remember any project I’ve worked on since I started doing professional software development that was assigned to me where I had a nearly complete lack of understanding from start to finish for a multiple week project (I’ve inflicted this type of pain on myself hundreds of times!).

Good news!

I think this was one of my final large projects when working on Cohort Lab. It started out poorly:

TL: “The other developer needs to work on an important data interface for a customer and he’s in the best position to work on that. We’ve also committed to finishing this other project that he had started working on and I need you to complete it instead. He’s made some progress though and it shouldn’t take too long to complete. He’ll be available to answer questions but the other project has a hard deadline.”

She went on to explain her general understanding of the project and the requirements. I met with the other developer so he could dump on me the work he’d completed and the documentation that was associated with the project. I can’t even sugar coat the wording there — dump best describes the transfer. PLOP. PLOP. The existing work was definitely incomplete and he hadn’t started what in many ways was the most important part. My sense is that he may have thought 70-80% of the project was complete. In reality, many parts had been started and some were more complete than others. It wasn’t 70-80% complete.

I stumbled into Levey-Jennings

The project was to implement a laboratory quality control charting system for Cohort Lab. In particular, the customer request was for a Levey-Jennings chart. Our documentation included one long academic paper from the late 1980s about how to compute and how a graph could be constructed. In addition to that documentation, we had some examples.

That was it.

The other developer had spent most of his project time building data structures and doing some of the calculations. I thought I’d never actually need that math I’d learned in high school and college. But, here it was…smacking me in the face and mocking me for selling my college text books.

No Rosetta Stone Available

I spent many hours trying to make sense of the code, the paper, and what was left to do. I know there are people that enjoy the writing style of a academic paper, but I am not in that group. The documentation and examples we had clearly were intended to be read by experts in the field. I wasn’t an expert. I didn’t even know an expert. Oddly, neither were our customers — they wanted the software to do this, but could provide no helpful guidance.

If you’ve been reading along with my Epic journey, you may remember that Cohort Lab was an application that ran entirely within a terminal. There was not a reasonable way to do “charting” on screen. Even with my skills related to manipulating the screen and drawing and animating various ASCII characters, creating an on-screen representation of this data wasn’t practical (80x25, or in wide mode a 120x25 characters doesn’t provide the detail needed).

Customers wanted to print the Levey-Jennings graph.

The printing that was common at the time used dot matrix printers. Fast and Loud (no, not the TV show, although there were many dramatic moments with the printer spewing and spewing followed by the panic of trying to halt it’s enthusiasm). And while The Print Shop could do some amazing things with dot matrix printers, the printer technology wasn’t up to the task of creating a professional graph.

Epic I think at the time had three laser printers and one of the printers was in the printer closet down the hall from my shared office. Laser printers weren’t very common. They weren’t very reliable at printing. Unjamming became my jam during this project.

So, I needed to figure out how to wrangle a laser printer into making graphics from MUMPS. The Epic printer drivers/engines were text focused. Actually, they couldn’t do anything but print text. I found some documentation that suggested how various proprietary options existed to communicate with the printers and print something other than text. PCL came up a few times, but customers weren’t consistently using printers that supported PCL then. To add to the complexity, connecting to the laser printer from MUMPS running on Unix (or OpenVMS) system, and then getting the printer to switch to PCL was very poorly documented (remember, no Internet!). I tried. I consulted internal experts. Epic was too tiny to have meaningful technical contacts at hardware manufacturers. That approach was abandoned as it seemed like it would be a project much larger than what I was working on (and there weren’t staff resources for that).

If you’re keeping score, … I didn’t understand the charts, the lab tests, the math, the terminology, much of the code that had been dumped on me, or how to get charts to appear on a laser printer.

We did have documentation available (man pages and a basic user manual) for a graphing system called gnuplot. (Sorry, the official website isn’t HTTPS!!, so here’s a Wikipedia article if you’re interested.). From their home page, it looks like version 2.0 or 3.5 would have been available.

Fade to a cool movie-like montage of a software developer looking at manuals and trying to understand how to piece these parts together into a releasable software package …

It took a while to get a basic set of moving parts together and operating. During the montage, my struggles included:

• how to install gnuplot
• how to shell out of MUMPS and execute a random application that could be installed in a variety of locations (the MUMPS answer to shell out is to use the BANG! syntax: !gnuplot)
• how to detect if it was available and the right version
• how to generate a file that could be read by gnuplot
• how to trigger a print to the laser printer after executing gnuplot
• how to delete the file after the laser printer had completed the print
• how to return to MUMPS after all of this, otherwise leaving a stuck MUMPS process that an IT admin would need to clobber

But, the real challenge — how to take all of this data that made very little sense to me and get it to print something that represented the graph that customers were looking for. I only had a terminal. In all but a few cases there was not a way for me to check the results without physically printing the page (I learned how to better read the gnuplot instructions so I could spot obvious issues).

Over and over and over. And over. I began to show progress to the team by taping each print to the walls of my shared office as high as I could reach. I filled 3 walls of the office. My step count went through the roof and there was likely a path worn from my desk to the printer closet from the trips back and forth. It took me a long while to get charts to print. I tried to make it enjoyable by hanging both successes and failures. Some prints would be empty. Some would have lines that went off the page, or were too small, too big, wrong, flattened, squished, stretched, … I had a fixed set of data that I was using so that I could know when I’d unlocked the secrets to Levey-Jennings Charts. I fixed some issues (math and data) with the dumped code as I honed in on getting a final result.

The project went long — I don’t know that I could have done anything differently though to expedite the work given the unknowns. For some reason, this project really didn’t click with me. I enjoy finding and fixing a bug way more than a project dump, especially of this complexity and with this many unknowns.

I know this was a project that customers selected and was important to them. But, it was miserable for me. It deflated me in a way that I rarely have felt over the decades. I knew the “parts”, but the “whole” remained elusive. I couldn’t find the passion I normally apply to my work. The end result was “clunky” at best as it required so many things to come together to get a successful print.

I was deflated. The result worked. But I could find no satisfaction as the project felt thoroughly OK for what it was. I couldn’t make it better in a reasonable amount of time with the information and resources that we had available. Rarely do I accept “OK” as it relates to my output. I expect myself to add to projects I’m involved with a bit of bedazzling but this project had nothing. No shine or glitter. No hidden gems.

It wasn’t even glossy: it was flat-matte.

It just existed as a hot-glued graphing contraption in the remote areas of Cohort. I didn’t know where a hint of sparkle could have been added.

Ugh.

My TL wasn’t overly surprised that I requested something “new” at Epic after completing this project. It was one of a few moments at Epic over the years where my conversation with a TL or Carl veered into the territory of me looking for other jobs. I had much much longer periods of my Epic career where I wasn’t doing something I enjoyed, but this project had really gotten under my skin. Too many unknowns along with the dump of code and not even having the satisfaction that the end that customers would use this regularly made it feel like a total waste of time to that young programmer.

I just asked my Cohort TL if she remembered any customer deploying any of this work…:

No.

🤨

Have you had any projects that just never clicked for you from start to finish? Tell me!