The Tale of the Data

I was a simple toolroom clerk working for General Dynamics back in the early 1980’s. My job involved stocking and issuing electronic hand tools to assemblers. One of the tasks was to maintain inventory and ensuring accountability for all tools issued to employees using their employee number. We used a NCR form (multi-paper forms using micro-encapsulated bubbles on the back of each page, excepting the final copy which when written upon burst and produced a carbon copy on the page underneath. We spent a lot of time managing a large box of tool receipts indexed by employee number.

Whenever an employee requested a tool, we would (technically) look first to see if an identical tool had been issued to same employee before issuing another. Well, at the beginning of shift the long line of employees knew we would not have time to rummage through all those slips of paper to see if they had duplicate tool issues. This poor inventory execution not only resulted in behavior by employees not bothering to see if they had a duplicatetool in their toolbox, but it also allowed many nice socket sets and diagonal pliers to find their way home. I had a few employees that pilfered generous amounts of tools knowing the weakness of the paper-based system.

My manager walked in one morning with a large box and a smaller package. He looked at both myself and my coworker briefly, then he handed the box to me (my co-worker struggled with a learning dyslexia) and instructed me to learn how to use this new Apple IIe computer and the DB Master database software. He wanted me to convert from a paper-based tool inventory system to a computerized one. He said that I was relieved of my toolroom window duties, grab a cup of coffee and to figure it out.
I had never touched a computer and I certainly never had even heard of a database. During the next few weeks I found my calling.

Now I had always had a proclivity towards handwriting manual lists of information on everything from notebooks, to ledgers to huge wall-mounted order lists. I was fascinated even as a young child with lists of toys and poring long tables of geographic country data. I loved how a database (albeit, non-relational) could organize data in a logical and easily retrievable manner. I not only learned to use that state-of-the-art personal computer, but how to design simple databases and to build reporting tools.

Well, soon I had my most notorious tool thief approach me for a pair of connector crimpers. This tool type cost over $100 dollars not including the crimping die set that he also requested. I asked him to please wait a moment. I quickly churned out on a noisy dot matrix printer a list of all tools that he had checked out and had not yet returned consisting of several pages. I returned to the counter window and displayed the column of the crimpers. I replied, ”I will be glad to give you another crimper after you return the other four that I have already given you.” He was furious and declared his boss would see about that! Well his manager actually worked with my father at this plant some twenty years earlier. When he returned with this manager, I simply showed him the list of tools issued to the irate employee. The manager laughed and walked away after turning to the employee and saying, “Isaak gotcha!”

Afterwards I went on to develop databases and reporting tools of ever increasing complexity and usefulness. Later, with the Boeing Company I found a new IBM-compatible PC sitting in our main office being left unused. Everyone was afraid to touch it. Well, I found that it had a relational database called Borland Paradox installed on it. Soon, I had access rights to the main frame database (DBII) and I was able to ask any question that a manager asked themselves about our inventory (this is significant, being able to query data for meaningful and useful information. Unorganized data by itself is tedious and largely unusable).

For instance, I was able to summarize the tens of thousands of tools used on the existing 767 airplane and adapt them as an order list for the new 777 program that was just starting. Quantities were added to selected tools after review by each airplane section build group and then we simply let a printer spit out boxes of tool orders to be delivered straight to procurement (this was before email became available). My fellow tool coordinators were delighted since they no longer had to hand type hundreds of tool orders on multilple page carbon paper forms and then later to be hand typed onto order status sheets. Later I learned how databases could be placed on brick-sized handheld computers for our tool rooms with the data uploaded with a docking station connected by wire to the main database.

I was on my way….

During my database career with the Boeing Company I would encounter someone laboring over data management using a spreadsheet. I have seen them all, from Lotus 1-2-3 to the latest products. I recall one gentleman who had an empire of time and cost devoted to a huge spreadsheet complete with embedded macros and images. By that time, I was with an IT group and I had received the request to speak to the spreadsheet designer since he had asked for a third hard drive in his PC. His hard drive order request justification described how he needed the extra storage space for maintaining the multitude of spreadsheets that he had broken his “database” into. Spreadsheets can be limited to 65,000 rows of information, but rarely hit that limit – but not this guy.

I recall the irritation every time that he proudly described his information repository as a database. I cancelled his hard drive request and instead authorized myself to kill this cumbersome set of data that was constantly at risk since it was never backed up. I developed a real database, imported his data and suggested that he return to the duties that he had been hired to do as a tool designer. All is fair in love and data…

Next: when is a spreadsheet not a database?