I’m Old, Part XVIII: Acrobat Lacks Absorbency

The Acrobat team was built with a decent amount of infrastructure by 1990’s standards. One problem that faced the team was that the product was designed out of the gate to run on multiple target platforms. Initially, it was MacOS (I think they were on System 7 at that point), Windows 3.1 or 3.5, and DOS. There was a UNIX version, but the demand was low so it trailed far behind.

Outside of writing code, this presents a problem because it means that the infrastructure tools needed to run cross platform as well. That meant that the bug database had to have Mac and Windows clients as well as the source control system.


For the bug database, the group used a 4D database as there were clients available for everyone. It ran like a dog, but it did the job.

When QA reported a bug, it was classified as A, B, or C. An ‘A’ bug was a crasher or significantly incorrect output. If you followed the steps, you would cause Acrobat to crash or in far too many cases, to take the entire machine down. B bugs were incorrect functionality or unexpected behavior. C bugs were cosmetic bugs, e.g. missing the ring around the OK button of a Macintosh dialog box or poor wording or a message that ran off the edge of a window.

One of the dreaded problems in software development is recidivation. You fix a bug and then at some point later in development it returns in a different form. For the most part recidivation happens when an engineer hasn’t fully understood the cause of a problem and has instead fixed an apparent cause or when the fix was in the right place but was fragile or a hack.

At one point, there was a piece of paper put up on a bulletin board outside of Bob Wulff’s office that read, “2-4-6-8, we will not recidivate!” I think it was put up by Jonathan Sjordal. It was a nice sentiment, but I don’t think it helped in any practical sense.

When working on a long-term project such as Acrobat, the development and QA engineers all tended to go non-linear. It’s not surprising. Acrobat was a project that falls into the category of “land-grab”. It was a product that had a clear spot in the market and we were trying to fill it first and before anyone else. Under those conditions, it’s not surprising that people go funny.

There was a bug report opened with the title “Acrobat Lacks Absorbency”. In the description, there was a test file that you were directed to print out, then you were supposed to take a dump and wipe with the print out and observe the results.

This bug was opened and closed and reopened and assigned and reassigned and commented and moved to QA and bounced to an engineer and then bounced back and closed and reopened and deferred and undeferred and closed and reopened.

If someone reopened or reassigned it, it was a clear sign that engineers were either tired or punchy or both. I think that particular bug set a record for the most number of comments on a bug. It showed up in morning meetings and I’m pretty sure that Bob face-palmed more than once when it showed up. He just couldn’t kill it.

Personally, I think it was a good sign when it showed up. It was an indication that people still had a sense of humor, no matter how crude.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.