PAIR OF DEUCES, PART 4

Nine months after the botched installations at Mark Chapman’s Trade Mark Office and Molecules R Us, Inc., it was a chilly late February morning in 1995. I was sitting at my desk on the second floor back at the Weehawken office. During this period, I was responsible for marketing with no, as in zero, authority to actually get much done.

Suddenly, I had developed a new-found interest in curing our software defects large and small.

Behind me, Steve was tapping away on his keyboard, probably writing code for the Olcott Intellectual Property Management Software (“OIPMS”). Peggy was around the corner, attending to some marketing follow-up. Yoshi was downstairs in the Computer Center, which was a large room featuring several PCs, a mini-computer, various computer parts like mother boards, dead mice, shells, and, bizarrely, in one corner, a portion of Palisades’ basalt protruding through the cement slab floor.

With no warning, Dad rolled into the room and announced, loudly, “Steven!” This was his way of saying that he wanted to meet and review OIMPS. Occasionally, this included major design changes. Which presented, at times, some very tough engineering challenges.

These review sessions were typically dreadful and sorry affairs. Frequently, they started by Dad walking in and offering “on-the-spot guidance” only to end by shouting insults to the computer department staff for errors mostly (but not always) provoked by him.

At best, Dad’s ideas added distinctive functionality that the competitors hadn’t thought of. Like a field for “Prior Art,” for example. You had to be a patent practitioner to conceive of features like this. And that’s where Dad had an edge. The competition consisted mostly of programmers and others that Dad, the real honest-to-goodness Patent Attorney, dismissed as “nerds.”

While Dad’s concepts were solid, sometimes, his timing was much less so. It’s true that in software development, like in all endeavors, you can’t think of everything all at once at the start. Typically, you devise improvements and extensions continuously as you go along. The trick is using a development device like a Parking Lot. Many ideas rightfully belong there — parked for the time being, until they can be prioritized — so as not to interfere with ongoing processes, like code writing.

Too many changes too soon can cause your engineering project to collapse as conflicting premises collide. At best, you get buggy software. At worst, you get constant crashes.

I had already suffered from both kind of faults. So, I was done with half-assed efforts. Our software development process cried out for tighter planning, stricter diligence and dedicated follow-through. Going forward, I had resolved to add this value to Olcott International.

Dad sat down next to Steve and called Peggy and me over, so we could watch him point repeatedly over Steve’s shoulder as he navigated through the fields on the screen. Notably, Dad never touched a keyboard or mouse, such tasks were apparently beneath him.

Maybe our software wouldn’t have crashed so much had he deigned to use and test it himself?

Dad started barking at Steve to flip through various fields on the main patent docket screen. Today’s focus was to be the aforementioned Prior Art field. He instructed Steve to click on the “Drop-Down” button next to the field. When executed, this opened a dialogue box with a scrollable list inside; the up and down controls were on the right side.

Dad, however, called it a “Pop-Up button.”

Drop-Down or Pop-Up button? Did it really make a difference what we called it?
In the general scheme of things, I have to admit, no.

A pop-up dialogue box.  See?  It asks questions.

But that morning at Olcott International, we were definitely NOT casual actors in the IT space. We were professional developers and marketers of word-class Intellectual Property software, in this case on the DOS platform (which Dad preferred to Windows). Specifically, we had the best design for patent management software in the business. A field to capture these Prior Art data in the Patent Header section of the screen was one of our distinguishing competitive advantages (among others).

There was one small problem.  And, dear reader, I use the term “small” ironically.

Something had gone awry in our software development cycle. As recounted in my previous Pair of Deuces essays, our software was quite capable of bombing, and at the worst possible times, such as in the middle of client installations on any of the three platforms. (Interestingly, our Windows version seemed to be the most stable, but I had the least experience with it compared to the others.)

That sour experience persuaded me that we needed to straighten out our development process by, among other things, being more precise in the design and implementation phases.  This would include more internal testing to identify and remove bugs. It was not acceptable to me that any of us should be out in the field and have the program tank.  Once was more than enough.

Just for review, a Drop-Down button looks like this:

If you are attempting to clarify an underlying problem, the first step is to define it using language as clear-cut and direct as possible. Dad would do this all the time in arguing. If he caught you using an imprecise term while making any kind of point, from trivial to essential, he would skewer you.

Now, all this might strike readers as excessively pedantic. Okay, I’ll admit it: it was. Thing was, using the Pop-Up label when you were talking about the Drop-Down screen element did nothing for clarity.  It was exactly the kind of nonspecific language that would spark virulent retribution from Dad.

Next week: Virulent Retribution from Dad.  (Without respect to my desire to elevate quality).