Tag Archives: Y2K

1991-1999 TSI: Addressing the Y2K Issue

Posted on by
2

The big fix. Continue reading →

In 1999 people were predicting an end to civilization because of the imminent arrival of a new century. Art Bell interviewed a doomsayer almost every night. Key software programs were expected to crash a few seconds into the year 2000.

The calamity did not happen. A few systems probably had difficulties, but no major problems were reported at all. In the late nineties employees and contract workers at companies around the world ad devoted a great deal of time and money fixing or replacing software that would not work as designed in the year 2000. TSI was one of those companies.

The software programs that we had installed at clients and we used in TSI’s office often involved dates. For example, every business that does billing needs to know whether the clients are paying the bills within a reasonable time. This involves a comparison of the date of the invoice and the effective date of the report. The routine that makes the comparison must know the year for both dates. As long as both dates are in the same century, the familiar two-digit version of the year will suffice. However, if the invoice date is in 1999 and the report is run in 2000, the calculation must be adjusted.

This aspect of the problem was relatively simple to solve, but in large systems like the ones that we had installed there were thousands of references to dates. The challenge was to find all the situations that needed to be fixed and to implement the appropriate changes in a manner that minimized the inconvenience to the user.

From our perspective the problem was twofold: the way that dates were stored and the way that dates were collected—from data entry screens or from other files. As we entered the nineties we had three groups of clients: 1) System/23 (Datamaster) users, most of which had extensive custom code; 2) System/36 users, most of which were ad agencies that had a lot of common code, but a mixture of custom and standard programs were stored on separate media for each client; 3) a few AS/400 AdDept users; 4) TSI itself, which used a version of the ad agency system on the System/36.

I decided to inform all the Datamaster users well in advance that TSI did not intend to make their code Y2K-compliant. Most of them were not surprised; IBM no longer supported the hardware. However, the sole user at one customer, Regal Men’s Store, begged us to make their system work in 2000. I replied that it would probably be cheaper for them to buy a new system. As it turned out the company went out of business shortly after year end without purchasing a new system.

Fixing each ad agency system would have been a monstrous job of minimal benefit to anyone. By January 1, 2000, their hardware would have been obsolete for a dozen years. So, I sent a letter to each suggesting an upgrade to a small AS/400. Only a few of them took us up on the offer.

We did create a version of the ad agency software for the AS/400 that was Y2K-compliant. Our employees used it for administrative tasks for about twenty years. We had a great deal of trouble marketing it even to the ad agencies that love their GrandAd systems. Fortunately, by 1994 AdDept sales had really taken off, and we did not really care too much about the difficulties of marketing to ad agencies.

The AdDept system had to work perfectly, and the transition must be smooth. We had already promised a number of users that it would be Y2K-compliant. I intended to spend New Year’s Day 2000 watching bowl games, not dealing with Y2K catastrophes.

Why, you may ask, was there even an issue with data storage? That is, why were the dates stored in a format that caused the difficulties in calculations? The answer lies in Moore’s Law, the preposterous-sounding claim that the number of transistors in a dense integrated circuit (IC) doubles roughly every two years. In point of fact, the astounding 41 percent growth rate applied to many aspects of computing—processor speed random-access memory, and the ability to locate and retrieve large amounts of data very quickly.

For TSI’s first handful of years in business the clients stored all of their data and their programs on diskettes with a capacity of only one megabyte1. Those users crammed years worth of historical data on these thin slices of film. To put this into perspective, consider this photo of an eight-inch diskette:

Storing the simple photographic image shown above requires more than seven megabytes. So, storing a file of the size of this one image—something routinely done in 2021 by cameras, phones, watches, eyeglasses and countless other “smart” devices—would require (using the technology of the eighties) eight diskettes and perhaps an hour of computer time. Much of TSI’s systems were designed in this era in which both disk and memory were precious commodities. Good programmers were always conscious of the the physical limitations of storing and manipulating data. The prospect of a client’s system crashing because it ran out of space for its data was a nightmare to be avoided at all costs. Everything was therefore stored in the most efficient way possible. The idea of using two extra bytes to store the century occurred to almost no one in the early eighties.

I could think of several possible approaches to the storing of data to circumvent the problem of the new century. The four that we considered were:

  1. Replace all of the YYMMDD numbers in every data file with eight-digit YYYYMMDD fields;
  2. Keep the dates the way they were but add a new field to each record with the date in the YYYYMMDD format and use the latter for comparisons, calculations, and sorting;
  3. Add a two-digit century field (filled in for existing data with 19);
  4. Add a one-digit century field (filled in with a 0 for existing data).

Rejecting the first option was an easy call. All of TSI’s systems had hundreds of programs that read fields by their position in the record, not by the field name in the database. If the total width of the fields that preceded the field in question, was, for this example, 50, the program read the six-digit date field beginning at position 51. This was not the recommended method, but it had always worked better for us for reasons that are too wonky to describe here. The drawback was that whenever it was necessary to expand the size of a field, it was also necessary to change or at least check every line of code that read from or wrote to the file. This could be an imposing task for even one field. Since a very large number of files contained at least one date, almost every statement that read, wrote, or rewrote data would need to be checked. If it needed to be fixed—or even if it did not seem to need fixing—it needed to be tested thoroughly with data that contained dates in both centuries. We had no tools for the testing, and every situation was at least somewhat unique.

Large and dangerous.

Attempting this for every date and season field was such a large and dangerous task that the only way that I would consider it was if, at the same time, we abandoned reading and writing by position and replaced it with reading by field name. I thought about it, but I decided that that approach would result in even more work and was only a little bit less dangerous.

I reckoned that the other three methods were roughly equal in difficulty and in the amount of time required for implementation. I eventually decided that the one-digit method would suffice.

There was one additional issue in the AdDept system. The first two digits of the three-digit identified the year. So, it was necessary to add a century field for every file that included the season number as well. The season was a key field2 for many files. Fortunately, it did not seem to be necessary to add the century to the construction of any of those keys.

The other issue concerned data entry. Users of TSI software were accustomed to entering dates as a number in the form MMDDYY, the way that dates are commonly written in the United States. The programs validated what had been entered by converting the number into YYMMDD format and checking that each piece was legal. The check for the year normally involved checking to make sure that it was within ten years of the system date. So, every validation routine needed to be changed because the date entered and the system date could be in different centuries.

All of the work was to be done on the AS/400. The first step was to locate all of the files in both the AdDept database and the agency database, which we called ADB, and to add century fields that defaulted to 0 at the end of the files. At the same time, every program that wrote records to these files was found. A peculiarity of BASIC helped us find these programs. BASIC associates numbers with files in each program, and TSI consistently used the same numbers for files. Thus every instance of updating of the job file contained the phrase “WRITE #22”.

A single callable program was written to calculate the century. Its only input was the two-digit year. It was incredibly simple. It set the century to 1 if the year was less than 80 (the year that TSI moved to Connecticut); otherwise it set it to 0. In BASIC it required only two lines of code:
CENTURY=0
IF YR<80 THEN CENTURY=1

This approach will work flawlessly until the program confronts dates that are in the 2080’s. If anyone is still using code produced by TSI when that happens, someone will need to come up with a rule for setting CENTURY to 2. I don’t lose any sleep over this possibility. Yes, you could say that we just kicked the can down the road, but who is to say that roads and cans will even exist in 2079?

A much more time-consuming problem was correcting all of the programs that produced reports or screens in which data was sorted by one of the date or season fields. I set up an environment for the Y2K project that contained both programs and data. Whereas it seemed important to insert the century field into all the affected files as soon as possible, the reports and screens would work fine for a few years and could be addressed one at a time.

I evaluated this part of the project to involve mostly busy work—repetitive tasks with almost no important decisions and no creativity whatever. We had hired a college student to work with us for the summer. I thought that Harry Burt and I could set up the projects for him. Harry, who had experience as a college-level professor, could supervise him and check his work. This method did not work out at all, as is described here, and it used up some precious time.

I may have overreacted to this setback. I decided to make this a very high priority and to assign it to myself. One of the programmers surely could have done it as well as I did, but I did not want to assign it to any of them because I did not want anyone I was counting on to consider their job as drudgery.

So, for several months I spent every minute of time that I could find fixing and testing programs to handle the century fields correctly. A few cases were trickier than I expected, but the coding was completed, tested, and installed before any of our clients started planning for the spring season of 2000, the first occasion that would requir the code.

I am not certain about when this occurred, but at some point I received a letter from, as I remember it, someone in the legal department of Tandy Corporation. It said that the company had received a letter from someone named Bruce Dickens demanding that Tandy pay him a proportion of its gross income every year to license the software that handled the Y2K problem because it must have used the technique of “windowing”, for which he had been issued a patent by the U.S. patent office.

The letter, of which I cannot find a copy, contained a technical description of the term3 as described in the patent and asked me two questions: 1) Did the software that we installed at Tandy use this technique? 2) Would TSI indemnify Tandy Corporation in a lawsuit over its use?

I answered both questions truthfully: 1) “This does not sound like what we used.” 2) No.

Dickens sent demands for payment to all of the Fortune 500 Corporations. He said that if they did not agree, the percentage of income required for the license would be increased.

I have searched high and low to find out how this situation was resolved. I know that the U.S. Patent Office scheduled a review of the patent, but I could not find a report of the outcome. I also could not locate any information about whether any of the companies that he had extorted ever paid anything to him or the company that he reportedly founded, Dickens2000. I doubt it. I found no evidence that he actually sued any of them either.

If I had been asked directly whether any of our code calculated the century using the year, I would have changed the code listed above to remove the IF statement and simply set CENTURY=1 in all cases and then answered “No”. A few months into 2000 employees of the companies that used the AdDept system no longer entered twentieth-century dates on new items, and the programs only used the code to assign a season when new items had been entered.

We did not charge any of our clients for the Y2K fix. A few people told me later that this was a mistake. Since our customers depended upon AdDept, and there was absolutely no alternative system available, we probably could have gotten away with charging them. The companies may have even set aside funds for this purpose. However, all of the AdDept users had software maintenance contracts, and I considered it our duty to keep their systems operational.

1. A bit is a binary storage unit; it has only two possible values: off or on. A byte contains eight bits, which is enough to store any kind of character—a letter, number or symbol. A megabyte is one million bytes, which is enough to store approximately eighteen Agatha Christie novels. However, it is not close to enough to store even one photograph. Videos require vastly more storage.

2. A key is a set of fields that uniquely identifies a record. A well-known key is the social security number. The VIN number on a car is also a key. A zip code is not a key because neighboring residences have the same zip code.

3. The most readable and yet comprehensive description of the windowing technique that I have seen is posted here. The application for the patent, which was granted to McDonell-Douglas in 1998 (long after everyone had decided on the approach to use), was (deliberately?) designed to appear much more elaborate than the two lines of code that we used.

1988 TSI: The First Crisis

Posted on by
3

Many factors forced a tough decision. Continue reading →

In retrospect it does not seem like that great of a crisis. However, I have a very strong recollection that Wednesday, August 17, 1988, my fortieth birthday, was one of the worst days of my life.

I intended to to go the office and work all day, but the employees pretty much insisted that I take the day off. I was alone in our new house in Enfield. Well, Rocky and Jake were around somewhere, but cats are seldom sociable during the middle of the day. I don’t remember what Sue was doing.

I also don’t remember what I did all morning. I probably either went for a run of four or five miles—the heat did not bother me in those days—or tended to my vegetable garden.

I fixed myself something for lunch. I always ate early. Then, as usual, I lay down for a nap. I may have dozed off for a few minutes. When I arose from the bed, a crushing wave of melancholy swept over me.

I must have had a book to read; I always did. However; I did not feel like reading.Instead, for the first and only time in my adult life, I got down on my hands and knees in the yard that faced Hamilton Court and picked weeds.

I had been told by our neighbor, whose name was Fred, that both the previous resident of our house and the one before him were professional landscapers. They left us a beautiful lawn of bluegrass on the sides that faced the two streets and zoysia grass in the back. There were almost no weeds when we moved in, and, despite four months of neglect, there were still only a few patches.

While I attacked the invaders into our greensward, I took stock of my situation as I entered my fifth decade on the planet. There were undeniable positives:

  1. I was healthy. Sue was reasonably healthy. She had recently quit smoking, and that was very difficult for her.
  2. Sue and I had a nice new house.
  3. We had two nice pets.
  4. TSI had a real office that was smoke-free.
  5. We were in the process of negotiating a big contract with a client that everyone had heard of—Macy’s. The wooing of Macy’s and the subsequent installation there are described here.
  6. For the first time ever TSI had a salesman who was aggressive and appeared to be competent.
Interest rates in 1988 were very high.

On the other hand, the mortgage meant that our nut at home was higher than ever, and our payroll was considerably higher than ever. IBM’s announcement of the AS/400 (described here) was very troubling. There was no provision whatever for the types of customers that we had been chasing for the last seven years. The new systems were considerably more expensive and less powerful for the models at the low end. I did not see how we could sell them to small ad agencies. The other software vendors could offer much cheaper systems. The alternative was to try to find larger agencies around the country with the budgets to buy more expensive systems. This was, from a marketing perspective, a new business.

Eventually we faced facts and leased an AS/400 model B10.

I could see more unavoidable expenses on the horizon, too. We would almost certainly need to buy an AS/400 for development and support of the Macy’s installation.

We faced a lot of difficult work in the upcoming months. We would need to do the work to assure that our system for advertising agencies worked on the new system. At some point we would need to address the Y2K issue that was beginning to raise its ugly head in the press. Our date functions would not work in the year 2000, which really meant 1998 or 1999.

We did not really have the programming staff to meet these challenges. I could not depend on Sue to help. Denise Bessette was excellent, but she only worked part-time. Sandy Sant’Angelo could help a little, but she could not handle anything difficult. There was no getting around it; the bulk of the work was going to burden my undersized shoulders.

I could not see how the current arrangement could possibly work. Unless we received several surprise phone calls in the next few months, we must depend upon getting a second and third user of the new system that we planned to develop for Macy’s. I did not think that I could possibly get that system as then envisioned to the point where it was reasonable to market it before the company (i.e., Sue and I—the only partners) ran out of money.

I think that at this point I need to address what I call The Curse.

Not bloody likely.

In nearly every respect my parents provided me with an exemplary upbringing. They somehow got me the medical care that I needed to overcome what could have been a debilitating birth defect. I did not have many medical issues thereafter, but they ably and promptly addressed my dental and vision issues. They paid for an excellent education. We had food, clothing, and shelter in a very safe environment. They let me follow my own interests. They let me play tackle football for two years, although I am positive that my mother thought that it was foolish. They did not even make me take dancing lessons after I threw a tantrum about it.

There was one thing, however. I remember distinctly them telling me on several occasions, separately and jointly, “Mike, we don’t care what you decide to do. We just want you to be the best at it.” Not “the best that you can be”, just “the best”. There is no “absolute superlative” in English. Unless a group is specified, it means “better than everyone”. In 1988 the world’s population was around five billion. In any endeavor only one of the five billion is the best.

So, by the standards that they had set for me, at age forty (40!) I was an abject failure. I had never been the best at anything in high school. If you took the worst quarterly grade average that everyone had, mine was the highest, but that counted for nothing. The goal was not consistency, it was supremacy. I was not the best at anything in college either. OK, I was the best debater at the University of Michigan, but I was not even good enough to compete in the National Debate Tournament. After that I was a horrible soldier. I was nowhere near to being the best actuary, if that even means anything. I was not the best debate coach, and, in the end, I could not see any path for pursuing that goal.

I was a really good programmer, but nobody considered me the best at any aspect. In fact, in the area that we had concentrated—ad agencies—we had apparently reached a dead end.

I did not articulate this line of reasoning even to myself as my pile of weeds grew, but it must have burned in my subconscious: At age forty this was probably my last chance to be the best at anything. But how?

From somewhere it popped into my brain that I had to fire TSI’s salesman, Michael Symolon, whose career at TSI is described here. The company had no choice1. We had to sacrifice marketing in order to get the new product ready. The income from the software maintenance contracts and the big Macy’s check might be enough to cover the payroll without Michael’s salary until I could get the product in good enough shape to sell to other retailers. It just had to. It would take a Herculean effort to accomplish all this, but I resolved to do it.

I felt horrible about this decision. I hated firing people. I only needed to do it a few times in thirty-five years in business. All of those occasions were awful, but this one was the worst. I felt that it was more my fault than Michael’s that we were in this position.

I told Sue my decision that evening. She agreed. I talked with Michael a few days later. I assured him that we would pay him his commission on the Macy’s project as soon as everything was completed. He seemed to take it fairly well.

One of the last things that Michael did was to schedule meetings for me in Chicago and South Bend, IN. In Chicago I was allowed to explain the AdDept system that we were about to install at Macy’s to IBM reps who specialized in retail. I knew that quite a few large retailers—Sears, Walgreens, Montgomery Ward, Marshall Field’s, and Carson Pirie Scott, to name a few—were based in Chicago. I thought that they would be very interested in being able to sell a new application and a (newly announced) AS/400 to a previously unautomated department. I am not sure why, but the reception to my presentation was disappointing. They did not even ask me many questions.

I rented a car to drive to South Bend for a demo of the GrandAd system the next day. I am not sure when this occurred, but my credit card was declined somewhere, maybe at the hotel in which I stayed in South Bend. I had to make a very depressing and stressful call back to the office to arrange payment.

We (or perhaps the IBM office) had done a mailing to all of the ad agencies in the area. Five or six had reported that they planned to attend. As usual, I loaded our software and demo data onto the System/36 at the IBM office. Only three people attended the presentation. They all sat together, paid little attention, and took no notes. After my presentation I talked with them for a few minutes. They were all from the same agency. They already had a UNIX-based system running a product called Ad-Aid. I asked them whether they liked it; they were noncommittal.

As I made the long drive back to Chicago that evening I mulled over what had happened. The more that I thought about it, the more convinced I was that the ladies in the audience were spies sent to learn the strengths and weaknesses of our system. This would ordinarily have made me angry; on that day it just depressed me.

For the next three and a half years I worked a large number of hours per week for fifty-two weeks of the year. We sent out a couple of sets of letters to advertising directors at large retailers across the country, and we received just enough positive responses to get by.

The second installation of AdDept (described here) was even more difficult than the first. Hecht’s, the third installation (described here), was a genuine turning point, but it wasn’t really until 1993 that we could consider investing in another genuine salesman—five years of scraping by with only one break, our short cruise of Greece and Turkey in 1992, as described here.

I think that I made the right decision. I cannot envision what life would have been like if I had chosen otherwise

1. Yes, we could have tried to borrow some money. However, we had no assets to use as collateral. The prospect of going down a path that might well have ended in bankruptcy seemed unthinkable to me. The idea of begging for money from relatives never occurred to me.

1998 TSI: The Third Crisis

Posted on by
3

Keeping Denise in the fold. Continue reading →

My recollection of many of the events portrayed below was fuzzy. I was not even certain of the year (1998) or the time of year (autumn) until I found a dated document. Lacking a good way of pinning down the details, I needed to guess at or be vague about some things.

Background: For me the period from 1995 through 1999 was the busiest, most exciting, and most stressful of any that I spent working for TSI. It was also the most potentially terrifying period. Our marketing director, Doug Pease1, had hit the mother lode and put us in a position to dominate the market on which I had decided to focus our attention back in the late eighties.

Most large retailers, especially department stores, were organized into divisions, and each division was responsible for its own advertising. So, when a large retail organization decided to name AdDept as the preferred system for advertising, we would usually install a system at each division. In 1998 the May Company,2 which at the time had seven department store divisions, had already endorsed AdDept. Doug had also negotiated installations for the three divisions of the Tandy Corporation3 and he convinced the people at Proffitt’s4 Marketing Group (PMG) to purchase systems for six of their divisions. In addition to these, Doug had also made headway at several other potential clients such as Elde- Beerman, Gottschalks, and Macy’s West.

In short, TSI’s business was finally booming. The challenge was no longer whether the company could generate enough income to meet the next payroll. The question—and it was a very serious one—was whether we could meet our commitments to all of these new installations, almost all of which required significant custom programming.

There were a few other issues as well. The twenty-first century was approaching. AdDept had been made Y2K-compliant from the outset. We also had produced a version of the GrandAd system for the AS/400 that would work in the twenty-first century. We needed to convert all of the software that we used in TSI’s office as well. These undertakings were labor-intensive and required extensive testing. The details of those efforts are described here.

The company therefore faced tremendous challenges in providing the software and support for commitments that I had already made and for the prospective contracts that were almost certainly imminent. Furthermore, the person who had at that point done most of the AdDept programming, myself, would undoubtedly be devoting much less time to coding in the next few years.

I would be doing all the installations and on-site training. I also accompanied Doug on many sales trips. I gathered all of the requirements for new code and wrote the design documents and programming requests. I wrote all the marketing materials and anything else that needed to be written, as well. I also ran the business and extinguished the most serious fires. Last but not least, I did the great majority of the research on new hardware offerings and new software techniques. I still did quite a bit of coding, but I now relied on the programmers for most of it.

Steve Shaw.

Fortunately, I had a team of all-stars to help. Sandy Sant’Angelo handled the support line, which during the late nineties was nearly always busy. She was quite good at documenting problems and making the customers feel comfortable. The programmers were Steve Shaw, Harry Burt, and Denise Bessette. Steve and Harry were both good programmers, and they were both familiar and comfortable with TSI’s programming standards. However, they had little knowledge of details of the AdDept system or the way that retail advertisers worked and thought. Early in 1998 Steve Shaw surprised me by leaving TSI to take a programming job at the Phoenix Life in Hartford.

Denise was extremely dependable. She was also very meticulous in her work habits and thoroughly familiar with both TSI’s standards and most of the basics of advertising. She told me that she did not want to travel, however. Therefore, I could not use her for any of the trips that I made to clients.

The Known Problem: I always tried to keep the employees—especially the programmers—happy. The work at TSI environment was, I think, generally positive. The company had very few rules. There was no dress code at all, although I expected the employees to spruce up a little when customers came to our office for training. I wrote up a short document that listed what we expected of employees. My door was literally always open.

TSI paid the programmers pretty well, and by the mid-1990’s we had implemented good programs of health and disability insurance and a 401K with matching contributions. Although I felt a great deal of stress during this period, I tried to avoid putting pressure on the coders.

TSI’s corporate ladder.

I understood that there was one problem that was inherent to TSI and other small businesses: there was little or no room for advancement. I could reward people for good work, and I could try to make their work challenging and enjoyable. However, it they were ambitious and wanted to climb the corporate ladder, there was not much that I could do. I suspect that this is why Steve quit. Similarly, if they were interested in a position with more responsibility, my options were likewise limited.

I tolerated—and even encouraged—a certain amount of creativity, but after Sue left the office (described here) in 1994. I made all the important decisions. It wasn’t that I liked exercising power. I just reckoned that none of the programmers were interested in managing the business. I would have been happy just to code all day.

As good as the staff was, our upcoming workload was so massive that there was very little room for error. I knew, for example, that Sue and I could not consider another big trip until all the installations were stable, which might take years. I also understood that I had to keep the entire programming team intact if possible. As I have explained in other blog entries, I figured that every time that a programmer quit I lost at least six months of my own productivity between the time spent looking for a replacement, training him or her, and correcting all the mistakes. Furthermore, there was never a good time to look for coders, but 1997—just months before Y2K raised its ugly head—was one of the worst.

Harry and Steve were good programmers, but I knew very well that the key member of the team for the next few years was Denise. Losing her would be a catastrophe that I did not want to contemplate. I probably should have worried more than I did.

TSI’s Telephone System: Each desk at TSI had a unit like the one shown at the left. The company had many phone lines, but no one, not even Doug or I, had a direct line. TSI had two phone numbers that outsiders knew about. One line was dedicated to customers reporting problems or asking questions. That line was answered by Sandy.

The other number was in the phone book and on our letterhead and business cards. We disclosed it to prospects, vendors, and a few others. That line was answered by the administrative person.

There were also two rollover lines. If a caller called either the main number or the support number, and that line was busy, the phone would still ring, but someone at TSI would need to press the flashing button for a rollover line to answer it.

TSI relied on this phone system until the business shut down in 2014. Doug and a few others pressed me to get a more modern system in which each person had her/his own line. A couple of times I priced out these options, but I could see no advantage that was worth spending thousands of dollars. Besides, I liked our phones. In my assessment, they had one overarching advantage. They made it much more difficult for employees to initiate or receive calls from the outside. There was also a fairly strong incentive to keep non-business calls short.

Harry and Denise dressed up for a TSI Christmas party.

Denise Bessette: Denise was the first programmer that Sue and I hired in 1984. The details are posted here. She worked full-time for a couple of years and then part-time for quite a few years while she finished her undergraduate degree at Smith College and then earned a masters degree at Trinity College. In 1993 she became a full-time employee again. We let her use Sue’s office, which was better than her previous location, but it was still less than optimal because Sue never removed all of her junk after she stopped coming to the office in 1994. We also gave Denise a substantial raise. I tried to keep her in the loop on what direction the company was going, but I did not set up any kind of a formal process for doing so. I should have, but I didn’t. My excuse was that I was away on trips a lot, and when I was in the office I was exceptionally busy.

I should emphasize that, even though we had worked together for many years, Denise and I did not have much of a personal relationship. She invited Sue and me to her house in Stafford, CT, for supper once in the eighties. We never reciprocated, presumably because our house was always a mess. I doubt that in all of those years Denise and I had talked about anything besides work more than a handful of times.

During the time that Denise had worked at TSI she had occasionally received phone calls from her husband, her mother, or one of her sisters. She might have received one or two calls from other people. In the fall of 1998, however, even I, who would ordinarily pay little or no attention to such a thing, noticed that she was receiving numerous phone calls from a “friend” named Jackie.

Herberger’s: My most vivid memories of this period were when I was in St. Cloud, MN, the home base for Herberger’s a chain of eleven department stores, 1300 miles away from TSI’s office. At the time I was installing TSI’s AdDept system on a small AS/400 in the advertising department there. A more detailed description of the installation is posted here.

The offices were on an upper floor of this store.

I only visited Herberger’s a few times. The occasion that I remember the most clearly was certainly not my first trip there. It might have been the second or third. I remember that it was rather cold, but the weather did not approach the frigid levels for which nearby Frostbite Falls is famous.

In those days the only way to reach St. Cloud was through the Minneapolis-St. Paul airport. Northwest Airlines sponsored a shuttle service to the St. Cloud Regional Airport5. I can’t remember whether on this occasion I took that flight or rented a car and drove. I am pretty sure that I stayed at a hotel that was within easy walking distance of Herberger’s headquarters, which was on St. Cloud’s main drag, St. Gernaine St. I am pretty sure that I stayed two nights and then flew back to Connecticut on the third evening.

The main thing that I remember about my first day there was that I called the office several times to see if everything was all right. This was beyond unusual for me. On most trips, unless I needed help about some problem that I had encountered, I seldom called more than once. I have always hated talking on the phone, even if it was to people I liked. I liked all of TSI’s employees.

I don’t think that I spoke with Denise on any of those calls. However, I got the distinct impression that something was amiss. Although there was nothing particular that provoked alarm, the feeling of impending dread almost nearly overwhelmed me. I desperately wanted to get back to TSI’s office to discover the details so that I could deal with the situation. Of course, this was not possible. I had made a commitment to get the system up and running at Herberger’s, and I could not abandon the project because of a nebulous feeling.

After my first day at Herberger’s I ate supper by myself as usual. I don’t remember where I dined or what I did afterwards. I might have taken a walk. I might have read a book. I might have watched television. I do remember worrying.

I always got very tired after dinner. Every night I took a shower around 9:30 or 10:00 and then went to bed. I sat in bed for a few minutes reading a book. I almost never got through more than one chapter before the letters would begin to swim around on the page. I would then turn out the lights. Normally I was sound asleep within a few seconds.

St. Cloud in 1997 had newer cars, but otherwise it looked just like this.

Not this night. For a few hours I emulated Bobby Lewis—“Tossin’ and turnin'”6. I decided to make myself physically tired. There were not many choices available for nocturnal exercise. I dressed and put on my coat and hat. I then walked around St. Cloud for at least an hour. I did not go far. I just walked up and down the streets. None of the buildings seemed to have more than three stories. The only other thing that I remember noticing was a Maytag or Whirlpool store that sold appliances. I had thought that these stores—mainstays of my youth—had gone the way of the dodo, but they evidently still persisted in St. Cloud in 1998.

I eventually drifted back to the hotel and tried to sleep. I probably dozed off for a while before it was time to prepare for work. I remember that I ironed my shirt while I listened to Vivaldi on my CD player through my Bose headphones.

I was running on fumes that day. I chain-drank black coffee to try to remain alert. I took notes on all of the things that the Herberger’s employees said that they needed AdDept to do. I knew very well that Steve VeZain at PMG had already made it clear to me that no custom code would be provided for Herberger’s. Steve said that they needed to adapt to the system that worked for everyone else. I called in to TSI’s office several times on that second day, as well.

I flew back to Connecticut that night in an even worse mood than the foul outlook that these exhausting trips usually produced. On the one hand I was frustrated because the AdDept system did not work the way that the Herberger’s employees wanted it to, and there was nothing much that I could do to help them. They had no clout with PMG. They were, after all, by far the smallest division, and they were on the wrong side of the Mason-Dixon line. On the other hand I was also very apprehensive about what I would find out when I went into the office the next day.

The Denouement: On my first day back in the office Denise confided that she had been offered a job as IT director at a fairly small company that used an AS/400. I am not sure whether she would have any employees under her or not. Truth to tell, I did not care much what kind of job it was. My sole objective was to take whatever steps were necessary to persuade her to stay at TSI. I also learned that Jackie, as I expected, was a corporate headhunter for an employment agency.

I tried to talk Denise out of accepting the job. I emphasized how important I thought that she was to TSI. She asserted that she was mostly looking for something new. She had been doing mostly the same job for thirteen years.The best that I could get out of her was that she would think about it overnight.

Denise usually arrived at TSI’s office at about 9:007. The morning following our conversation I went outside to meet her in the parking lot. I was extremely nervous when her car finally pulled into the lot. She got out and immediately informed me that she had decided to accept the other job.

I cannot say that I was surprised, but I was still crushed. I couldn’t face going back into the office. So I went and sat in my car and moped. I felt as bad or at least nearly as bad as when Bill Davey and I just missed qualifying for the National Debate Tournament in 1970 (described here) or when Sue abandoned me to go to Alaska in 1973 (described here). No situation in the intervening twenty-three years came close to evoking this feeling.

I had no idea how to deal with this situation. We had mountains of work. I was in no position to take on more of it myself, and I could only squeeze a little more out of Harry. I had made commitments to several clients. I could not select one or two to work on and dismiss the others. They all had deadlines, and they had given us deposits or were long-time clients that I was not prepared to disappoint.

Sitting in the car was not helping. I drove to the Enfield Square Mall, parked my Saturn, went inside, and walked around. At that time there were some benches inside. I rested on one of them every so often. Eventually a plan coalesced in my mind. It seemed like a good idea; I just wish that I had thought of it earlier so that it would not appear that I was being extorted.

That evening I discussed my idea with Sue. I honestly thought that it would be as difficult to persuade her to agree as it would be to convince Denise. I was wrong. She understood the important role that Denise played, and she agreed in principle with everything that I proposed. She also knew that I was miserable.

I located the original written proposal that I presented to Denise. It was somewhat different from what I remembered. Here is what it said:

Denise as Principal:

  1. Denise will have 25% share8 in TSI. The three principals will have monthly meetings to go over the results of the previous month vis-à-vis the business plan and discuss other issues. The 25% share will entitled her to a presumptive bonus of 25% of the profits after employee bonuses and SARSEP contributions. Denise will give up her commissions.
  2. Denise will be given a budget of $125,000 for fiscal 1999. She will have six objectives:
    1. Do what it takes to bring our staff up to strength.
    2. Work with Doug to come up with a profitable and sustainable business plan for current products: fee schedules for programming and support, etc. The deadline for this is April 1, 1999.
    3. Come up with a concrete plan for TSI’s next software (or whatever) product. The plan should include recommendations about whether it should be done inside of TSI-AdDept or in another milieu. The deadline for this is September 1, 1999. TSI will pay for necessary travel. Mike has several frequent flier round-trips to use.
    4. Come up with suggestions to ease tension and make work fun for everyone. This involves removing the “Wag the Dog” orientation we now have.
    5. Implement remote dial-in support and a LAN (TSI will pay for the hardware).
    6. Get someone AS/400 certified or figure a way around it.
  3. Suggestion: Use part of the budget to hire Steve back in a new position. I would like to get five man-days of programming/support from the two of you, but this won’t work if there is not a firm system in place to guarantee freedom from support calls. The easiest way to accomplish this would be to work from some other location (which requires remote dial-in support).

I met privately with Denise on the following day. She was stunned by the offer and very impressed. However, she had already made a commitment to the other company. Moreover, there was another employee at the other company whose fate was somehow linked to Denise getting hired. I don’t remember the details. In any event Denise accepted my offer, I got our lawyers to make it legal, and she called the other company and Jackie. Neither was pleased.

This the first page of TSI’s revised stockholders agreement.

When I spoke with Denise, I made it clear that the monthly meetings would actually include Sue only if Sue insisted on attending, which I doubted would happen often. When we actually distributed annual bonuses, we gave Sue a minimal one and split the profits 50-50. The “concrete plan” became AxN. I do not recognize the “Wag the Dog” reference, but within a year the company moved into a new office in East Windsor with a remarkably different atmosphere (as described here). The “someone” who became AS/400-certified9 was myself (as described here). Denise did not hire Steve Shaw back. Instead she hired Brian Rollet, who was something of a disappointment to her.

Denise and I worked together amicably and productively for another sixteen years. If she had not agreed to my plan, those years would have been been much less pleasant for me. I don’t know if I could have achieved half of what we accomplished together.

1. Much more about Doug Pease can be read here and in many of the blog entries about clients that he persuaded to purchase AdDept in the nineties.

2. TSI’s involvement with the May Company at the corporate level is posted here.

3. TSI’s dealings with Tandy Corporation are detailed here.

4. In the nineties Proffitt’s Inc. purchased all of those chains and turned them into divisions. After it purchased Saks Fifth Avenue, which already used AdDept, it changed its name to Saks Inc. TSI’s relationship with this company is described here. Separate blogs describe the individual divisions.

5. In 2021 this shuttle is no longer in operation. The only commercial flights from STC are on Allegiant Airlines. There are only two potential destinations—Fort Meyers/Punta Gorda and Phoenix/Mesa. Residents who want to fly anywhere else must somehow get to Minneapolis. Northwest Airlines filed for bankruptcy in 2005 and was acquired by Delta in 2008.

6. You can listen to the number 1 single on the Billboard chart for all of 1961 here.

7. Denise asked for this allowance when her son was young. It gave her time to get him off to school or wherever else he was headed. She also had a fairly long drive to Enfield and even longer to East Windsor. She often stayed late.

8. When TSI incorporated in 1994, Sue was given 45 percent of the stock, and I got 55 percent. The revised agreement left me with 40, Sue with 35, and Denise with 25.

9. IBM had implemented a new requirement for business partners. Not only did the software need to be certified, but also someone at each company must be certified by passing a test that was sales-oriented and a test that was more technical. I took both of these tests, as is described here.

1981-1985 TSI: A4$1: The Beginnings

Posted on by
Reply

Anything for a Buck: Getting started. Continue reading →

We never turned down a project.

I have pretty clear memories of most of the clients1 from the very early days of TSI in Rockville, but I did not remember how we managed to develop the software for the first few. All of them except one either bought a new Datamaster or already had one at their offices.

The only computer to which TSI had access was a 5120. Both the 5110/5120 and the Datamaster used the BASIC programming language, but there was no easy way to convert code from one system to the other. If we did not develop the systems for new customers on the 5120, how did we write the code? I was pretty sure that we did not park ourselve in the client’s offices for weeks on end. For one thing, that would inhibit cursing, and it is not really possible to write good code without giving vent to a great deal of foul language. For another, we would have had to meet the client’s dress code every day. I would have certainly remembered that.

Sue reminded me that IBM in those days endorsed the policy of having the software developer take delivery on the customer’s hardware. The system would then presumably arrive at the customer’s location a short time configured and ready to use. Needless to say, this approach lasted only a few years, but it definitely gave struggling developers like us the opportunity to write a lot of software and simultaneously to put aside enough money to buy a system of our own.

This was accounting in 1980. By 1990 the columnar pads were an endangered species.

TSI’s first Datamaster client1 was our accounting firm, Massa and Hensley. Looking for a system to do time and material billing, they had purchased the tabletop model of the Datamaster. We met with them and designed a system that used three diskettes: JCPROG, which held all the programs, JCDATA for the keyed tables, and JCDET, to hold the transactions. The system had the following tables:

  • A table of client-related data that was keyed by a three-digit client number.
  • A table for each job opened for a client. The key was a concatenation of the client number and a five-digit job number.
  • Two job cost tables. One had every transaction; the other had the summary of costs by category. This arrangement violated the rules of normalization, but it facilitated some requirements. By the standards of the day the detail file was gigantic.
  • An employee table that was keyed by a three-character code.
  • A table of cost categories that also had three digit keys. The categories were of two principal types: time and materials. The entries in the time categories consisted of hours worked on a job. The entries in the materials categories were dollar amounts.
  • A rate table with a key consisting of the employee number and the category number. It might also have had a date so that they could increase rates to keep up with inflation.

The JCDATA diskette also had a table for a batch of transactions. This table might have been keyed by a letter so that more than one batch could be open at the same time.

My recollection is that there was only one menu on the JCPROG diskette. The user would place the program diskette in drive 1 and key in GO JCMENU. GO was a system command (ass opposed to a BASIC command) and JCMENU was the name of the program that displayed the menu of options.

Employees at both Massa and Hensley and Harland-Tine filled out forms like this every day. The category numbers were printed on the form. The employees knew by heart the client numbers and job numbers on which they worked.

Every day the operator keyed in a batch of transactions. The source documents were time sheets from the employees and other forms for billable materials. The program checked to see if the JCDATA diskette was in drive 2. If not, a message was displayed on line 24 of the screen to put it in. The entry and editing programs validated each field (client number, job number, employee number, category number) as it was entered. It printed a record of the transactions as they were entered. Transactions could be edited or deleted. When everything seemed correct, the program to update was run. The user was told to remove the JCPROG diskette from drive 1 and to insert JCDET. The records were then written on the history file on JCDET. Summary records at the job level were also written.

There might have also been a program to produce invoices to send to clients. Mass and Hensley may have opted just to produce a cost sheet for the jobs that they wanted to bill. I don’t remember.

We finished this project pretty rapidly, and everyone liked what we had done. Previously they would have had to rewrite and calculate costs for the information from the time sheets onto cost forms for each job. So, this was an ideal project for an early eighties software system. The savings in time and the increase in accuracy of costing and billing were immediate and substantial.

The users must have called TSI for support a couple of times, but I cannot ever remember when we needed to “put out a fire” for them.

TSI’s standards fit on one page, but they were strictly enforced.

Since I was doing the bulk of the programming, I implemented a set of standards for all of the programs. The goal was to make it as easy as possible to understand and debug them.

  • Many BASIC programmers eschewed the GOTO statement and use the RENUM command when they have changed their programs. I never renumbered the programs. Instead ,certain types of statements ALWAYS were in the same range of line numbers:
    • Line 1 was always OPTION BASE 1, LPREC. That meant that all counting started with 1, not 0, and all numbers had as much precision as the system could handle.
    • Line 250 always opened the specs table, and subsequent lines read in whatever specs were used by the program.
    • Lines 10000-10999 opened the tables used by the program.
    • The main loop of the program started on line 15000.
    • The exiting routine started at 60000.
    • Program-specific subroutines and functions were located on lines in the 70000-89999 range.
    • Headings for reports were subroutines that started at 90000.
    • Detail lines on reports were subroutines that started at 90000.
    • Reusable functions were 95000-99998.
    • Sections of code were separated by comment lines consisting of asterisks or dashes.
  • Every program had a meaningful number.
    • 1-99 was for programs to insert new records into tables or to work on existing records.
    • 100-199 was for lists of items in tables on the screen.
    • 200-299 for transactions.
    • 300-399 for printed lists of items in tables.
    • 400+ for reports.
    • The program number was in the upper right corner of every screen and every report.
    • Program listings and variable cross-references were placed in accordion files by client and program number.
  • Variable names were consistent and meaningful. CLNUM was used for client number in every program. Looping variables were always I or J. Counting variables started with N. NEE=NEE+1 would be used to count the number of employees selected.
  • In this version of BASIC all files were accessed by a number between 1 and 255. We consistently used the same number for a file. The printer was always #255.
  • Although BASIC allowed reading in all of fields at once, thereby assigning values to all of the variables with the corresponding field name, we never did this. If we had, we would have not been able to use the same field names for the same concept in different files. Instead, we read in only the fields that we needed by their position in the file. The disadvantage was that if we decided to change a field, e.g., to make it bigger, every program that referenced that file needed to be changed.
  • Disk space was precious. If a customer ran out of space on a diskette, it was a catastrophe. To save space all numbers except codes were “packed” to fit nine-digit numbers in five bytes in every layout. Dates were stored as six-digit numbers in the form YYMMDD. This all worked fine until the late nineties when we, as well as everyone else, needed to address the Y2K problem.
  • The screen layouts were consistent, and the behavior of Cmd keys2 was also consistent.
    • F2=Online help for every screen.
    • F3=Orderly exit.
    • F4=List of items in a table.
    • F12=Cancel and return.
  • The screens validated every field as soon as it was entered. If it was not accepted, the reason for the problem appeared in bold print on line 24, the alarm sounded, and the cursor remained at the field. This worked very well for the 5120 and the Datamaster, but when a single computer had many terminals attached, it became important to minimize traffic going to and from the server. Our programs on the System/36 and AS/400 therefore validated the entire screen at once. Problems were still reported on line 24 of the screen, the alarm still sounded, and the cursor was positioned at the source of the problem.

By and large these standards serve us well. We never really abandoned any of them.

This rather simple project was memorable not so much for what we did but for what it led to. Our accountant, Dan Marra, had a client named Harland-Tine, a new advertising agency in downtown Hartford. The two principals were Dave Tine3 and Susan Harland4.

I have dozens of vivid memories of this installation. At our first meeting Dave introduced himself as the president of the agency. He did not say what his partner did, and, in all honesty I never saw her do anything but cook. I think that they might have attracted clients by wowing them with her culinary skills.

A complicated business.

Dave said that the agency desperately needed to become more organized and efficient. He said that he turned to IBM for help, and both the IBM rep and his accountant had told him that he should talk to us. He envisioned using the computer for all of the administrative tasks of the agency. We spent a couple of days talking with people there. A large part of what the agency did was analogous to what Massa and Hensley did, but there was a whole other side to their business. They also purchased media (newspaper and magazine ads and radio and television commercials), which they marked up and billed their clients. Sometimes they created and produced these projects in-house, but most of the time some or all of the work was done by other companies or freelancers. There were a lot of other miscellaneous things that they also billed—public relations consulting, billboards (always called “outdoor” even if it wasn’t), direct mail campaigns, and “collateral”, which covered virtually anything else that promoted products or services.

They also wanted a billing system that could handle every type of work that they did. They wanted fairly standard accounts receivable, accounts payable, and general ledger systems. Their payroll was handled by an outside service.

In the early 1980’s Hitchcock not only manufactured chairs, but also had several retail locations.

The agency’s ultimate objective was to analyze the profitability of each client. Producing the reports for this was a very complicated assignment. Each client had negotiated a separate agreement with the agency. Harland-Tine billed some clients for items that others got free. For example, the agency’s largest client, Hitchcock Chair, was billed a monthly fee but did not pay anything extra for media expenses. They only paid what the publication or station charged the agency. So, if Hitchcock ordered a lot of media in a month, Harland-Tine did a lot of work with no reimbursement at all.

In addition, some jobs were billed in advance, some when the job was completed, and some in stages. So the profitablity reports, which we called “cost accounting”, needed to match the period in which income was counted with the period in which expenses were incurred.

We did not have the wherewithal to put together a detailed proposal. Instead we outlined in fairly broad terms what we would do for them. We broke it out by module, but we knew that it was really all or nothing. Their most important objective required all of the pieces. Our proposal was a great deal for them. We were desperate, and we did not want them to start looking around.

We saw ourselves in half of what agencies did.

Sue and I immediately noticed the resemblance of this agency to TSI. They were another company that would do anything for a buck! We decided that when we designed the system for Harland-Tine, we would also make sure that it could be used by TSI as well. We did not purchase media on behalf of clients, but pretty much everything else that the agency did had an analog in the way our company did business. For example, we did not advise about public relations, but we did consult about connectivity and hardware decisions.

I did a little research and discovered that there was a paucity of computer software for advertising agencies. Moreover, there were many agencies within driving distance, especially if New York and Boston were included in our sphere of influence. I figured that the best way to make TSI profitable was to sell a base package with customization to a lot of agencies. We had to start with one or two happy and successful clients. We resolved to make Harland-Tine the first.

Detailed recollections of the installation itself can be found here.

1. We never called the people who paid us money customers. We thought of our business as more service than product. We never installed a system that did not include at least a modicum of customization.

2. There were no function keys on the Datamaster keyboard. Instead there were 24 active Cmd keys in BASIC programs. The user held down the Cmd key in the panel on the left and the appropriate numeric key on the QWERTY portion of the keyboard for the 1-12 Cmd keys. For 13-24 (seldom used by TSI) the user held shift and Cmd and pressed the appropriate key (less 12). Shift Cmd 1 was 13, Shift Cmd 2 was 14, etc.

3. Dave Tine’s LinkedIn page is here.

4. Susan Harland died in 2000. She and Dave Tine opened the Connecticut Culinary Institute in 1987.Her obituary is here.