The Purple Flash
I’ve been thinking a bit about my “career” as a developer over the past 25 years and there’s a few stories that stick out in my mind. Moments where I learned something or observed something that made an impression on me and seemed to embody this job of making software.
In the mid-90s I was working at a software company in southern California that made online learning tools. The mid-90s is when “online” still just meant connected to a network, any network, and so much of our work wasn’t internet based, but installed on networks inside of large companies.
The software we made was loaded onto computers and shipped to the customer who would then use them to train and test their employees. Imagine you’re a fast-growing global shipping company and you need to teach 100 new employees every month how to use your internal software. We’d write software courses the employee could take and get tested on that would generate reports to the administrator who could be assured the new employee was trained.
We distributed not only the software but the hardware as well. And so when after a major release we started getting reports of a “purple flash” on the displays during startup, the investigation began. The developers stopped what they were doing, grabbed a production unit from the lab, and dragged it into the area surrounded by our cubicals.
A few things here: I was a very junior member of that team. The code was all C and OpenGL and I had joined as a Java/HTML developer with less than a year of writing applets under my belt. I was 100% a spectator through all of it. But it was exciting to me. My job to that point had been fixing text rendering bugs and nudging form fields that had bled into instructional copy. Suddenly I was able to watch more advanced engineers dig into a problem that confused everyone.
And second understand that this wasn’t important. It wasn’t important on the scale of THINGS WE HAVE TO DO and it wasn’t even important on the CUSTOMER IS ANXIOUS ABOUT X list either. It was a small bug on a very long list of bugs, and technically it wasn’t even our bug, but something we should pass on to the hardware vendor.
But there was this flash…
The computer sat on a tiny table and we crowded around it. One of the developers flicked the power switch and the computer booted up, BIOS messages scrolled past, and then there it was: the purple flash. The screen went from black to a quick flash of purple for a half second. The actual title screen followed and the test was ready to be taken.
Something I just remembered about the Purple Flash incident is that the color was actually magenta, one of the components of CMYK, but for the next couple of weeks it became known as the Purple Flash. Someone did contact the video card manufacturer but they either never responded or simply thanked us and added it to their bug pile. I never remember hearing from them about this.
The Director of Engineering did not sit in the (self-named) engineering pit. Only the programmers did. So at this point nobody outside of us and customer support knew about this issue. It was all anyone could talk about that day.
For the next few weeks work went on as usual but front-of-mind for every engineer was the Purple Flash. It was immediately determined the video card driver included in the update caused this, but because that patch was a compiled update given to us by the manufacturer it was difficult to debug. At the edges of the workday conversations about the Purple Flash would break out. One of the engineers actually had video driver experience so he demonstrated how you could step through the instructions on the chip and tweak them so code took different paths.
Nothing he did made it better.
Naturally by this time others on the team had heard about the Purple Flash. The Director of Engineering (my first real engineering manager) was well aware of it. He joined in sometimes to hear the latest theories about the problem while making sure we covered more pressing work. He never once told us to stop and seemed to enjoy the subject when it would come up, but never more than just understanding it was a novel problem for us.
Days passed and ideas came and went.
Eventually it was solved. An engineer figured out one night that during startup a memory location contained garbage data that consistently, when flushed to the display, rendered the magenta color. That was the problem. The solution was still to be written, but now everyone was excited about it again.
The fix ended up being, according to my memory, a trick. They couldn’t stop the driver from reading from that location or the garbage being written in the first place, but they could alter the garbage data just enough so that when flushed to the display it rendered the exact color of the title screen. The quick splash of color still happened, but nobody would notice.
The Purple Flash incident felt like it was quickly forgotten. A system level patch was QA’d and released to the client and I don’t think it was ever spoken about again. But for some reason it’s stuck in my mind all these years for a few reasons.
First it made me realize what it felt like to actually be on an engineering team. To actually work together toward a goal. To watch engineers bounce ideas off each other and build off each other’s talents and experience to get to a solution. Even as a spectator I felt like I belonged.
Second I realized much later when I was a manager myself, that it was a healthy, positive diversion for the team. I’m sure our manager knew this back then and that’s why he never discouraged work on it. He had a team that worked well together and having these diversions, where the whole team could sink its teeth on a problem, was good for it.
Finally, the solution was clever. Given a multitude of constraints and dead-ends, systems that were opaque and out of our control, the fix turned out to be possible with a very tiny bit of code inserted at just the right spot.