It’s the Fall of 1978, and your then 22-year-old author is tired of defending the cause of software engineering in a $10M-ish revenue organization where an acceptable solution to the “programming problem” would be to kill all the programmers.
As I had one foot out the door, the CEO of said organization grabbed me by the scruff of the neck and dragged me into the CFO’s office, where I observed about 3 feet of paper covering most of his desk area. He then dragged me into the parts cage, where inventory was manually recorded on paper cards filed in plastic tubs. Calling this arrangement ‘Jurassic’ would be generous by one or two eras.
At this point the CEO said “you seem to know something about computers. Perhaps you would like to help us improve this situation”. I knew that the CEO had recently been at Radio Shack, and could imagine his dreams of a cheap TRS-80 solution. So I decided to test the waters - “Perhaps. But I’m not interested unless you’re prepared to do it right. Given the current state-of-the-art, 'right' means an investment of about $100,000”.
The CEO doesn’t blink. So I upped the ante. “I’d also like complete control of the budget and schedule”. I figured that would be a deal-breaker. Nope.
One last try: “I’ll give you 10 months. I’ll implement inventory, bill of materials, A/R, A/P and order processing. When it’s done, I’ll hire a replacement and be gone”.
Done, done and done. Great.
Now what had I gotten into?
My first order of business was to march into the manufacturing VPs office for a lesson in how manufacturing was done in this operation. I began to document all of the systems I encountered, surfacing requirements for automation. I also did this with the CFO and Sales VP, and a pretty clear (and standard) picture emerged.
I should note that common practice at the time generally included selecting hardware first. My observers were chagrined that I was looking for a software package that would meet the requirements, and THEN I would find the hardware to run it.
Things are a little better today. But not much.
I discovered an outfit in Englewood CO called The Automated Quill that made just what I needed. A “plus” was that all of the source code, except for a small runtime library, was supplied as part of the deal. Language? FORTRAN. Their host of choice? Data General. I did several customer reference calls with positive results, and then went to visit their East Coast distributor for some quality hands-on time. Everything looked good, so we placed an order for a system: hardware, about $81,000 (including a $6,000 printer), software, about $28,000, for a total of about $109,000. This was one of the biggest purchases the company had ever made. No pressure.
Some of you will remember that this was a time before instant gratification. We were put in the Data General order queue and given a expected delivery date of “sometime in a few months”. While we were waiting, I began to design the physical facility and get all of the inventory data entered into digital form so we could hit the ground running when the hardware finally showed up.
So far, things were going like clockwork. I had a reel of tape with the inventory data ready to go and we had nice room for the new hardware. The system got delivered, passed acceptance test and I loaded the applications software, then the inventory data. Presto! Then I ran a ‘dead inventory’ report…drum roll, please…$80,000 worth of dead inventory appeared and could be written off. Not bad for the first week. I was feeling pretty good…
The good feeling eroded dramatically when I tried to do the first bill-of-materials (BOM) explosion. For those who don’t know, a BOM is just a complete list of every component used to build a product, grouped by sub-assemblies. A BOM explosion is a depth-first tromp through the hierarchal structure, listing every component. When I did this at the vendor site, everything was quick and painless. When I tried the same thing at our new installation, the result was: “<partno><part data>…go out and get a coffee…<partno><part data>….get another coffee and a danish while you’re at it…<partno><partdata>…” We’re talkin’ slow. Unusable slow. “This is on me and I’m really screwed” slow.
The good news? I tried this after hours and was the only one to witness the disaster. But now what? Why was the system so slow?
The answer had to be in the code somewhere, and I had the code, so I began reading reams of FORTRAN to see if I could detect anything amiss. Nope. All looked fine. Damn. I needed to see deeper. Remember that non-supplied library? I called the vendor and politely told them that if they didn’t send the runtime library code, well, it would be ugly. After much screeching and gnashing of teeth, I finally got it.
Now we’re deep into DG assembler, uncharted territory but what the hell, how hard can it be? It’s now the weekend, just me and mountains of listings, and streams of invectives that thankfully go unheard….
…and then, the light bulb goes off. As I’m reading the assembler, I came across a pair of disk I/O instructions that were issued for every record access. One of the instructions created a channel that could be read. The other instruction read data from the channel. The first instruction could take a very long time, depending on the device being read. Remember the demo visit? The demo installation included a honking, expensive 300MB disk drive. We couldn’t afford that, so we opted for the cheaper 20MB drive. Would you like to guess which one was faster? And, the channel was being defined FOR EVERY RECORD. Ouch.
I sharpened my pencil and added code to not assign a channel if it had been set previously.
It was 3 lines of assembler.
I re-ran the BOM explosion. It was 40 times faster.
I then hit my favorite bar. Rather hard.
Things went smoothly after that. By the 10-month deadline, I had identified and hired someone out of an IBM VS shop that wanted to learn about the new world of computing, and I packed my suitcase to hit the road for Ed Yourdon.
But that’s another tale from the IT crypt.
[Editor's note: This installment of "tales from the IT crypt" displays the humor, technical chops and tenacity Lou Mazzucchelli will bring to his role as Moderator of Summit 2021: Taming Exponential Challenges. Having experienced some pretty wild times early in the digital age, Lou uses these experiences to inform his viewpoints on the technology transformation that's happening all around us. Since nobody appreciates a good story more than Lou, he's the perfect moderator/judge for the Summit Lightning Talk segment, where attendees tell their own tales, rapid fire!]