Eternal Y2K Lessons

When NASA reported that we weren’t all going to die in September, 2015, I had flash backs to the 2012 hysteria and Y2K fears that combined technological disasters with the Rapture. Obviously, the world didn’t end, but it provided some interesting lessons that I still use today.

These events occurred early in my career, nearly straight out of college. Names (except my own) and places have been changed to protect the innocent and avoid being charged as guilty of making fun of the employer.

I was learning to enter production orders into our MRP system. When I entered a resin processor equipment order with a delivery date of six months out, it processed and came up as 99 1/2 years late. I chalked it up to my own mistake. Then resin orders for almost a year in advance, fall 2000, showed up as 99 years late. I asked one of the purchasing staff what I was doing wrong. “Mary” said, “Well, I’m ordering equipment and resin stuff for next year, and I’m getting the same mistake.” Ah, so it wasn’t just me. So we took it to the manager, who took it to IT.

Welcome a true Y2K nightmare.
Our MRP software wasn’t Y2K compliant. Worse yet, our MRP software was no longer supported by IBM. The option were:

1. Buy big name software package.
2. Buy little name software package.
3. Make our own software.
4. Deal with it.

Since it was summer 1999, option 1 wasn’t an option. All the big name software vendors were too busy to talk to a small sized manufacturer, while freelance programmers made a fortune fixing the calendar bug so common that a few people thought it would shut down the computing world. Small software vendors were willing to talk to us, if we paid a great up front fee to get them to show up. Given the limited purse strings of the manufacturing firm, paying for a software vendor to grace us with their presence – but not necessarily solve the problem in time, was not an option.

Thus option 3, making their own MRP software in house, was the option that was selected. A computer science graduate straight out of college was hired to develop a new MRP software application. And, amazingly, one was developed by October and installed.

The training session was by a guy trained by the guy who developed the software, then left to make a fortune in last minute Y2K contracting. I asked so many questions that the 30 minute training session lasted 1 1/2 hours. I took detailed notes, since they had not had a single handout on how to use the software. Many questions I had couldn’t be answered, except with the answer that only the programmer would know and he wasn’t here. Then came recommendations from the programmers to try the software after I installed it and see if what I thought would work did, indeed, actually work. Frightening thought, when you think about it. Beta testing should be done before production releases.

When the training was over, I typed up my notes in a Microsoft Word document. Since there was no hand out to the users, I wanted to create my own for reference. I e-mailed the notes to the trainer with the single line: “Is what I wrote correct?”

Two hours later came a mass e-mail to the whole company, with my notes attached. The only line in the message was: “Here’s the user guide for the new MRP software”. Thus began my technical writing and IT documentation experience.

Thus the new homegrown application was “released”. There were minor bugs, but it was Y2K compliant. Orders placed 18 months in advance showed as over a year out, as they should. It seemed the Y2K bug was fixed on our system.

January 2nd was filled with trepidation. No one was actually in the office January 1, 2000, to see if it rolled over correctly. If civilization was going to collapse, there was no point babysitting computers.
The first work day arrived. All our computers turned on. All the equipment turned on. The additive feeders fed additives at the right rate. Level measurers showed correctly. None of the mechanical devices ripped out of the wall to chase employees down the corridors, a la The Simpsons Halloween special. Disaster averted.

Then I went down to the process control center. There was a long string of blinking lights. The date display on all the equipment controllers was flashing 00/00/00. The one software system no one had bothered to check. Individual units were too stupid to care what the date was; the central controller unit, though, had no idea what to do.

There were three eternal Y2K lessons learned from the experience.

1. Figure out all the software that needs to be fixed before you begin trying to fix it. This is otherwise known as requirements definition.
2. When you’re writing – or rewriting – software, document how to use it before you try to train people how to use it or expect them to use it
3. Make sure the trainers are thoroughly trained in the software before they train users. If the trainer cannot answer questions, the questions will filter up to development. And that is not a value added proposition.