PAIR OF DEUCES, PART 2

A software installation is the natural follow-on event to testing and demonstrating. Both start with a lot of preparation.

I love the analogy of an honest-to-goodness dog and pony show.  Set up and rehearsal are key.  The poodles are washed and clipped, their manes and tails festooned with ribbons. Ponies, for their part, are brushed and adorned with headdresses.  The hoops are lit up just before the show.

The secret sauce is figuring out which doggie biscuits (or horse apples) the little bastards will die for. Once known, the tricks and jumps will be perfect.

It’s the practice, of course, that makes everything run like clockwork. You get to see the idiosyncrasies of all performers, providing the necessary insight to separate those that don’t play nice with each other. And, of course, you lead with the pairs that shine together. 

But enough with the wildlife parables. All the practice with the test data and the demos lead to the main event, the client install.  Instead of inputting fake data into the PC in your own office, you input their real live data — patents and trade marks — into their machines in their office. Your own rehearsals with your own pups has, in essence, trained you in handling their curs, so to speak.

Back to my story from “PAIR OF DEUCES, PART 1.” I had a live body, a Mr. Mark Chapman, who had committed to buying our oldest management system, the one running on DOS.

I remember having words with my Dad that afternoon about his comment that our company was “was not in the trade mark management software business.” For fuck’s sake, we ARE in the software business, I said to him indignantly. And, on top of that, I have a paying customer.

Leading with my own stellar doggies and ponies thusly, Dad was uncharacteristically at a loss for words. Maybe he was embarrassed for a change. I had to admit, I was starting to become ever less tolerant of his shenanigans. This was, after all, business.

So contracts were written, installation disks prepared, and Mark’s PC was documented and verified as to system specs. Which shouldn’t have been all that necessary since our battle-ax DOS system could run on any electronic appliance from lava lamps to toasters. Well, okay, just about. The fact was, our DOS program was written on a wide assortment of wild clone computers over the years. Many different programmers. Nothing documented.

And I spent extra days of rigorous practice, inputting trade marks and then running numerous reports showing the data in useful arrangements.  Finally, the big day came and I drove down to Mark’s office in downtown Washington, a few hours away.  After the usual greetings and small talk, I unpacked my disks.  It was show time.

I loaded the program onto his DOS machine and introduced the layout. As discussed above, there was no User’s Guide; this was strictly show-and-tell.

My plan was straightforward.  First, my fingers would tickle the ivories.  Then it would be his turn.

I asked Mark for a trade mark to input and he handed me a US registration replete with details.  Turning to the screen, I explained how the top half of the screen was for details of the initial home registration. The bottom half was for related registrations in foreign countries.  “See how you can scroll through them all?,” I asked.

Each data field in sequence was accessed by hitting the tab key on the keyboard. I input the description, and then hit tab. The next field was Category.  “This field is a drop list. You select the correct category like Word, Badge, Service, etc. here.” Mark nodded in comprehension.

Next was a field for search results; before filing for a new registration, you always conducted a search to make sure no one else was already using your proposed name anywhere in the world. Otherwise, you ran the risk of an inbound lawsuit and having your registration nullified.

In this manner, then, I proceeded through each field, made clear the purpose, sought the correct details, and made the necessary inputs until the last one.  So far, so good.

But, as a vendor, I knew full well that the magic of software is not in the hands of the teacher.  It depends very much upon what the student does with his or her own fingers on the keyboard.  I completed my inputs, saved the data, and then passed the baton to Mark.

He picked up a new trade mark and started his inputs. He was experienced with computers, I could tell, and he knew his stuff about trade mark law, far surpassing my own knowledge. After all, he was a certified practitioner.

With each field, I could tell he was rapidly gaining confidence with his entries, quickly moving on to the next via the tab key. One, two, three. I was feeling gratified and proud of the Olcott International team. This really didn’t take that much training.

About 5 minutes later, Mark got to some date fields. He input a date and then had to input a date category like registration or first use. He dutifully made his input, hit the tab key to progress to the next field, and nothing happened. The cursor did not budge. He hit it again. Zippo.

“Here, let me try,” I offered. I watched in vain as I hit tab repeatedly. The cursor just sat there, motionless. So I took the mouse (yes, we had mouse functionality in DOS) and clicked on the next field. Problem solved.

Except it wasn’t. Mark wanted to know why the tab key didn’t work. I had no better answer than it was simply a glitch. Something, I added, hopefully, that the programming team could address and resolve. “In the meantime,” I added, “I have given you a meaningful work-around until this little bug could be properly resolved.”

Unfortunately, Mark was wondering, like many people can and do, that if something this small was wrong, ‘what else was wrong with it?’  Something of terrible import, no doubt. I knew otherwise from experience that this was a good program, it was installed in numerous offices, and had received high praises for its design and  functionality.

Some people, however, once having persuaded themselves of something, are never to be disabused of their notions. He had managed to invalidate the program due to an insignificant detail.

On another level, however, Mark was right. There really should not have been any such defect in consistency. Maybe it was the fact that the software had been written by a myriad of programmers with no documentation or that the work had been done on a multitude of driverless-component clone computers that booted erratically on suspect parts.

Mark was unswayable. Whatever the reason for the glitch, he could not accept the program “as is.” Even though he acknowledged that my work-around was easy and solid.

I packed up my gear and left. I never saw Mark again and drove back to my home in New York City upset that OIPMS-DOS had let me down. Truth be told, I was more than annoyed.  And I was determined to implement more attention to detail back in the office.

Next Week: Part 3

My desk this afternoon in October 2017.  Still plagued with bugs…