So... I was enrolled in the very first class, of about 20 students, in Data Processing, at the Iowa Technical Education Center (now called Indian Hills Community College). I moved to Ottumwa, found some roommates, and we rented an apartment in a big, old building high on a hill overlooking the river and the highway, west of downtown Ottumwa. Our class was all male, except for one woman (a fact later to become extremely significant). Our school facilities were located in part of a large old Naval barracks at the Ottumwa airfield. The many old Naval buildings remained from pilot training during World War II, and they were still in quite good condition. Other courses were offered in other buildings, such as a Cooks school. The DP staff consisted of a Director, 3 instructors, and a School Secretary (who was the daughter of a former Iowa Governor, and who had been personal secretary to Senator John F. Kennedy, now President of the United States (another fact soon to become extremely relevant).

The school had a considerable amount of equipment, including a Burroughs B-200 business computer and a full line of IBM Tabulating (pre-computer) equipment... a Sorter, a Collator, keypunches, and a 407 Accounting machine.

At that point in time, there were few computers in use. Most business processing was accomplished on Tab(ulating) equipment. Since that equipment has almost completely disappeared from the scene now, let me describe the equipment and processes in some detail. It’s important to understand that most of the same processes now accomplished by use of computers was done on Tab equipment... such as Personnel recordkeeping and reporting, Accounting, Inventory, Payroll. The simple, amazing, but true fact is that it was done at least as well as it is now. Not nearly as quickly, nor with the immediacy of access to data, but in a few case, perhaps more conveniently, and I believe, at lower cost than now. I’m not suggesting that we revert to those methods, but I am trying to emphasize that computers have not revolutionized business methods, as is often believed. That view is touted by those who do not know the past.

Tab equipment

Tab equipment used punched cards... light cardboard cards, about 8 by 3.5 inches in size. The card (technically called a Hollerith card, but generically called an IBM card) had a predefined format of 80 columns that could be punched, using codes of 1, 2, or 3 holes per column.

Keypunches

The holes were punched on a keypunch machine... by an operator typing at a keyboard. The keypunch machine translated keystrokes into the holes to be punched. Operators sat for shifts, keying data. Blank cards were fed from a feeder that held about a handful of cards, and punched cards were moved into a stacker with about the same capacity. The operator placed a new handful of cards into the feeder when necessary, and removed punched cards when the stacker got full. The characters represented by the punches in each column were printed across the top of the card.

Card Sorters

Sorters were often shown in movies and on television, supposedly to represent high tech. Their visual appeal was that cards were fed from a hopper on the left, passed under a single-column reader, and then went to one of a dozen stackers, depending on the contents of that single column of punches. The later, faster model sorter passed and sorted cards at a rate of 1000 cards/minute... which was indeed impressive to watch. To sort a deck of cards on a 3-digit code, for example, required sorting the cards 3 times... first on the 3rd (least significant, or minor) column, then on the 2nd, then on the 1st, or major column. Sorts on an alphabetic field, such as a name, were typically only on the first few columns. Considerable care was required when doing elaborate sorts to insure that the columns were sorted in precisely the correct sequence. A deck of cards could easily consist of many trays of cards. Typical trays were about 3 feet long, with a sliding divider to hold the cards upright. When sorting a deck (file) of cards, all of the deck had to passed for the most insignificant column, then the whole deck passed for the next column, etc. Big sorts involved a great deal of card handling by the operator, who, on occasion, would hold up to 2 feet of cards between his hands when moving them from one place to another. A common prank was to yell and toss something to an operator, and then laugh if the operator lost control of the large deck of cards. Cards would fly everywhere, and much sorting time would have been lost.

Collators

The purpose of a Collator was to merge 2 decks of cards together, based on the information on the cards. A collator used a wiring board to control the comparison between cards.

Wiring boards

On the Collator and the Accounting machine, wiring boards were used for control... a simplified and crude form of programming. The board itself was simply a large, thick metal plate filled with rows of circular holes. Specifics sets of holes corresponded, and were so marked, for, in effect, memory locations within the machine. Special wires, with a connector on each end, were used to connect one set of locations to another. The connectors, when in place, extended thru the board. When the board was placed into a special tip-out tray and then closed into the machine, the wire connectors made contact with the controlling logic inside the machine. The wiring board for the Accounting machine was large, about 18 inches square, and contained perhaps 5,000 holes. Wires of different lengths (and correspondingly different colors) were used, depending on the distance to be spanned. A complex wired board could have many dozens of wires, so neatness was essential. Special wires, called jackplugs, were used to connect holes that were next to each other. Wiring schemes were often so complex that they were first drawn on paper, on special preprinted forms showing the layout of the board. These forms then served as documentation of the processing step. A business would have many wiring boards that would be kept with the wiring in place, so that rewiring would not be necessary. Again... these wired-up boards were the predecessor of programming, and had to be tested and debugged in the same way. I recall wiring one complex board for the Accounting machine, and having it perform absolutely nothing. Thinking that it might be a bad wire somewhere, I wired another board to match. It also did nothing.

Accounting machines

The IBM 407 Accounting Machine was the heavyweight of Tab equipment. It was huge... perhaps 6 feet across the front, and 4 feet deep, standing chest high. The major portion was a large printing mechanism in the center top. 14 by 11 inch continuous paper was fed from the back, looped upward near the front, where a single line at a time was printed, at a rate of approximately one line/second. It was quite a noisy printer, because each character was printed from a vertical bar that ratcheted up or down to the character for that position. There were 132 of those bars across the paper. When all 132 were in position with the correct characters lined up, they were struck against the paper, thru a carbon ribbon, printing a whole line at once. The overall sound was ka-chunk, ka-chunk, ka-chunk. You could audibly tell about how many characters were being printed, versus spaces, and, for an application you were used to running, you might be able to tell what part of a report was being printed, just by the sound.

The input to an Accounting Machine was, naturally, a card deck... the only output was a report.

Burroughs B-280 computer

Our program at Iowa Tech had the use of a B-280, and a full-time technician to maintain it. It was not unusual for a company to rent a computer with the technician included. Although not as large as some computers in use at that time, the B-280 was quite advanced, because Burroughs Corporation was big on research and innovation, while IBM dominated the market through powerful marketing. The B-280 model was roughly equivalent to IBM’s 1401 model of the same period.

Again, punched cards were the input to the B-280, but it also had tape storage, and “high-speed” printer output, as well as being able to punch cards.

The B-280 was programmed in Assembly language, which was virtually identical to machine language except for being able to interpret 2 or 3-character “op codes” rather than their numeric equivalents. As with most assembly languages, the programmer had to move data in and out of hardware registers to get almost anything accomplished. To give you an idea of the size of computers, the central processing unit on the B-280 was about the size of a refrigerator, but twice as deep. Memory was 4.8KB (4,800 bytes... actually not bytes, but 7-bit characters... 6 for data, 1 for parity). By way of contrast, the PC I’m writing this on has 8 MB (8,000,000 bytes) and has a cpu box half the size of a microwave oven, with a lot of extra stuff in it. Each of the 4,800 memory positions could be addressed by a 3-character address. Memory was mapped into sections, fields, and characters, with 40 sections of 10 fields of 12 characters each. In the 3-character address, the first character addressed the section, the second addressed the field, and the third character addressed the position within the field (special characters were used in addresses, in addition to digits). Primary input, via the Card Reader, was at a maximum rate of 200 cards/minute. A faster reader, rated at 800 cpm was also available. The card punch could operate at 300 cpm.

One of the antique features of a computer system, at any point in time, is the printer. The B-280’s printer was as good as any at the time... rated at 700 lines/minute. All printers of the day were so noisy that they had a padded container, including a raisable door to get at the paper. All printers used continuous-paper, fed on sprockets. The Burroughs printer used a printing drum with 64 characters around and 120 character positions across. Paper feeding was controlled by a continuous 11-inch loop of paper tape with holes punched at positions you wanted the program to be able to skip the paper up to, such as the top of the next page, bottom of the page, etc. These paper tapes were punched by hand, and the computer operator might have to change paper and the paper tape for each job run. Many preprinted forms were used, since computer printers could only print text, and not very attractive text at that. Actually, preprinted forms made output very sophisticated and attractive, often being printed in more than one color, with shading. Later in my career, I designed many elaborate preprinted forms.

All computers of the day made great use of magnetic tape... reels of 2400 feet of tape, each of which could store up to 15 million characters of data. Naturally, records stored on magnetic tape could only be processed sequentially, one at a time, in order, as opposed to the random access of date we’re now used to. In fact, that is not a severe limitation, since most business processes are naturally batch processes, with every record in a file being handled, often in the same sequence. Computer systems of the day typically had from 2 to 8 tape drives, each about the size of a refrigerator... each quite like a large audio tape unit, with a take-up reel. The operator had to mount tapes, and remove them when finished. As I write this, tape drives are still in use.

Burroughs' primary market was the Banking industry, and they manufactured special equipment for that market... MICR (magnetic ink) equipment, that used stripes similar to those now found on the back of credit and bank cards. MICR documents ranged up to 11 x 14 inches in size, and could be printed on, but the stripe still held only 80 characters of information.

Computers of the time used magnetic core memory, composed of tiny rings made of material that could be magnetized and demagnetized by current flowing through the 2 wires running through each ring. Seven rings (cores) were required for each character position of memory. Core memories were a mass of wires, strung by hand during manufacturing. This technology was expensive, produced significant heat, and limited the amount of memory that could be accessed, simply because of the length of the wires needed, which was enough to cause timing difficulties.

At that time, computer rooms were typically enclosed spaces with heavy air conditioning and raised flooring to accommodate the heavy cabling.

Curriculum at Iowa Tech

Our course was one year in length, with classes all day, 5 days a week, with considerable homework. Not only was our school free to us, as were books, but we were paid a per diem. I don’t remember what amount it was, but it obviously was enough to survive on.

Course work included Basics of DP, Computer programming, Tab equipment, fairly heavy Accounting, and related subjects such as Math. Our instructors were really pretty good and in spite of the fact that the school, course, computer, and everything else were brand new, we learned Data Processing well enough to easily enter the growing field. We spent a great deal of time on the Tab Equipment, a fact I’ve never regretted even though I spent little time using it after school. It was an excellent basis for learning computers, and some of the important concepts have been useful to me... concepts not taught any more. As in many fields, having to produce results with inadequate tools forces one to develop techniques, methods, and tricks, a few of which still apply.

One interesting homework project I still remember was our “computer-dating” for a dance at the local high school. Students filled out a brief questionnaire, and our job was to match couples for a specific dance. My partner on the project was the one woman in our class, Judith Barnett, (who later became my first wife). We keypunched the student responses into cards, then by sorting them numerous times, matched boys and girls according to our personal scheme. We were told that we matched up some couples who used to date or still did. I believe our results were the best of any of the teams.

I had 3 guys as roommates, and we lived in 3 different places during that year. Roger was the epitome of a geek... smart, shy, uncool, wore glasses, etc. Doug was a big dummy from the farm, who just got by in school. Chet was a tough little guy. I remember him being quite short... short enough that he had to buy pants in the boy’s section of stores. We didn’t have a lot of spare time.... it seemed as if we were always studying Accounting (which may be why I still hate it), but we spent a good amount of time at a bowling alley on the east side of Ottumwa, and at a little tavern downtown. Ottumwa was an interesting town... being a river town, it was old, and had been a center of meat processing. Housing ranged from virtual castles to the only tar-paper-shack slum I’ve ever seen in the U.S. It was not far out of town, and was seriously pathetic. I was shocked. Like most river towns, there had been great discrepancy between the rich class and the poor class.

One day at school, in November, not long after we had gotten there, perhaps the most memorable event in recent American history occurred. President Kennedy was assassinated. This event was powerful enough to affect all Americans, but it had a personal connection for us, because our school secretary had been his personal secretary when he was a Senator. Since we were a small group, and since we had much contact and fun with her, the killing took on a personal note for us. She (wish I could remember her name) was a delight... outgoing, personable, and had a habit of saying things that could be misconstrued as being sexual, which would make us laugh and embarrass her. She was the kind of person you just had to like and care about. Physically, she reminded me of Olive Oyl. As I mentioned before, her father had been Governor of Iowa at one time.

I would have to say that my year in Ottumwa was a good one. I learned the basics of a career I still work in, over 40 years later. I met and dated a very attractive, extremely intelligent, somewhat crazy woman. All of this was particularly delightful since I had just come from 4 years of mostly drudgery in the Navy. It was a great change. I had expected to learn a hot field in the Navy, but was disappointed, so Iowa Tech was just what I was looking for. I had no trouble getting a job immediately after graduation, in Des Moines.

My first position in Data Processing, at a significant insurance company. Banker’s Life had a rather dominant position in Des Moines, on High Street. As with most insurance companies, it was a rather formal organization. I remember long rows of desks, that there was a gymnasium and indoor swimming pool, and that employees were treated well. There was a computer room, with an IBM computer that had perhaps 8 tape drives. They had not had the computer for long, and most of the company’s work was still being done with Tab Equipment, all contained in one large room... perhaps 25 different devices... sorters, collators, etc. Banker’s had a couple of antiques (even old for me) that were still in use... a single-column hand punch, and an IBM 650, which had a drum memory. The drum was perhaps 16 inches in diameter.

The large computer was still being used to emulate the 650... it had not been there long enough for much programming to have been done. Emulation was common then... systems software designed to run jobs designed for an older computer, with little or no reprogramming or other change required. Emulation was not necessarily faster on the new computer than it had been on the old computer, but it was used to survive until new programs were written to make full use of the new computer.

I worked at Banker’s Life for only 3 months, as a Sorter operator, handling cartfuls of trayfuls of cards... on my feet all day. I took a room at the YMCA, which was actually pleasant... decent rooms, with pool tables and other activities available, and a nice view of the river.

Judy Barnett also took a job in Des Moines (funny I don’t remember where) and had a small duplex where she and her son and daughter lived. I remember little of that 3 months besides work. I do remember helping Judy paint a wall in the duplex... dark gray. We were continuing to hang out together.

I left Banker’s Life when I was offered a position back in Iowa City, at Measurement Research Center, with an increase in pay and to be a programmer, not a Tab operator.

Measurement Research Center was located on Market street, 2 blocks east of Dubuque, and across the street from the venerable John’s Market. I don’t know whether MRC was a profit-making corporation or was organized as non-profit. Like so many other groups connected with education, it looked internally as if it was profit-making, but presented an outside appearance to the contrary. It had some kind of close connection with Iowa Testing. MRC certainly operated as competition for private commercial companies, such as NCS, who I later worked for. While I worked at MRC, a great deal of test processing was done... scanned on MRC’s own scanners, then scored and analyzed on computers.

While I was there, I worked on analysis and reporting of an Iowa statewide student system. MRC’s primary internal computer was an IBM 1460, just a step up from the 1401. The 1460 was pretty equivalent to the Burroughs B-280 I learned on at Iowa Tech... a card-reader/punch, printer, and 4 tape drives. Programming on the 1460 was done in the Autocoder language, an assembler language, a small step up from machine language. It might be surprising to a modern reader to understand that a computer program did pretty much the same amount of processing that modern programs do. Thirty or forty pages of code printed on 11 x14 greenbar paper was, and still is, common 30 years later. The methods were crude: Programs were hand-printed on coding sheets, punched into cards, run through the Assembler program, producing a smaller object card deck and a printout. The Assembler probably detected errors, which the programmer then corrected with more code, more keypunching, reassembly, etc., until a clean assembly was achieved. Then the program was tested, gathering the needed data on cards or tape... output produced and checked, then back through the whole loop again. Even data itself has not changed much during that time, except to take more space. In the early ‘60’s, a character required 7 bits... today each character takes 8 bits, which provides a wider range of characters. Data format, on cards or on tape, was fixed-format, and most data is still in that format.

After I took the position at MRC as a programmer (or programmer/analyst?) I moved in with my parents, who had recently purchased an almost-new house in Coralville, in the Lantern Park development. Not long after, Judy Barnett also took a position at MRC and rented the first floor of a house in Iowa City. Later that year, Judy and I got married and I moved into that house too, on the east side of Iowa City. At that point in computer history, growth was great, and opportunities were similarly great. One could change jobs at will, and be assured of at least a 10% increase in pay by simply moving... so there was a lot of movement. I might add that employee benefits were relatively insignificant at that time. People were used to taking care of their own health problems, and benefits were not so important in retaining employees. Because the industry was still pretty young, each of us wanted more responsibility, more challenge, and the chance to produce more creative solutions. Even then, I didn’t care much for programming (still don’t) but preferred design of systems.

My memories of MRC are not of the work I did, but of personalities. The Manager of MRC was Pete Wahl, a big, young, Li’l Abner sort of guy. Normally, Pete was casual and affable, but he had an enormous temper. I recall walking into our 2nd floor facility one Saturday, shortly after I started there. As I opened the door, a metal chair flew past the door. After a pause, I peeked in. On the left side of the room, where the chair had been headed, was a pile of 3 or 4 chairs. To the right, walking away, was Pete Wahl. As further evidence of Pete’s temper was a lower panel on a piece of computer equipment, permanently caved in by Pete’s big foot. I saw him angrily kick an open drawer in a card cabinet, moving the whole cabinet back several inches as the drawer slammed shut.

I acquired a working habit from a supervisor of mine at MRC... a habit that I retain to this day: to attempt to get work off my desk as soon as possible, by doing it immediately rather than scheduling it. There is a down-side to that habit, but it has the advantage of working on a task when it is most fresh in my mind. One employee at MRC, Jim Slaughter, later ended up working with me in Minneapolis. Another, Burdette Hansen, may have been my first experience with someone of very little talent except politically, who would become successful. He was something of a joke at MRC, with the nickname Bidet. I recall that it was generally accepted that he tried to cheat at card games, which we always played at noon. In general, MRC had a cadre of very bright, creative young people.

Historically, it’s important to understand that, because the industry was new, technical capability was critically important. Computer organizations were small, innovation was the key to getting work done, and organizational/political skill was less important. Hence, many DP people were rather strange people... individualistic, rebellious, bright, opinionated, and egotistical... who took their work personally. Many would not be hired by today’s corporations, who place more of a premium on image and corporate compatibility.

In 1965, I got my first real opportunity at design, as part of a position in Minneapolis, at Scientific Computers... a job that was advertised in Iowa newspapers.

When I applied to Scientific Computers, I was given the directions that it was across the street from the Curtis Hotel. Not only did I come across a small map showing the way to the Curtis, from all over the midwest, but they also had signs along the way to Minneapolis.

I was somewhat sick during that trip, later determined to be chicken pox. The position was as an Analyst/Programmer, creating systems to do processing for schools. Because of my experience at MRC, I was offered the job, and later accepted, after consulting with my recently-acquired wife, Judith Barnett. We had been living in the southeast part of Iowa City, and we both worked at MRC, in equivalent positions. Judy and I both graduated from the first class in DP at Iowa Tech.

The position at SciComp was a good increase in pay. While in Minneapolis interviewing, I did some research on the local prices, to help evaluate whether it was indeed a real increase in income. I recall checking food prices at the Great Northern Market on Hennepin Avenue, right downtown... long since gone. The cost of living did not seem significantly different in Minneapolis, compared with Iowa City, so we decided to make the move, and I accepted the position.

Judy and I made a trip to Minneapolis together, and hunted for living space all over the Minneapolis area, eventually finding a nice little duplex in Columbia Heights, a few blocks south of 694. Our move to Minneapolis, the first week of June in 1965 was unique. I had reserved a U-Haul truck. That week is extremely busy in Iowa City, with University of Iowa students leaving for the summer. When I went to pick up the truck, I was shown that the whole top of the box had been sheared off... about the top 4 inches. The previous user had tried to drive it under the Iowa Avenue Crandic bridge, which was about 4 inches too low. At that time, I would not have been able to find another truck anywhere, so I decided to use it as it was.

We got the truck all loaded, and left our home. Within a few blocks, the sunny day turned rainy. I pulled into a Phillips 66 gas station, under their protective, triangular-shaped roof (also gone now). The rain persisted, and we were stuck... a truck filled with our stuff and no top. Couldn’t go forward... couldn’t go back. It wasn’t raining hard, but it wasn’t stopping either... and we had 300 miles to go. The Amoco station across the street had a tarpaulin covering their tires display. I talked them into selling it to me, and we covered the truck with it... all but about 6 inches at the front... it was just too short. With little choice, we left Iowa City in that condition, Judy, Byron, and Tanya following in our 1965 Corvair. As so often happens in Iowa, the weather changed again within 15 minutes... changed to one of the heaviest downpours I have ever seen... one of those that forces everyone to simply pull to the side of the road because it was impossible to see the road. Within a couple of hours, we had made it to the south side of Cedar Rapids... about 20 miles from Iowa City. We decided to stay the night there, knowing we couldn’t possibly drive through to Minneapolis. When I checked the tarp over the truck, I found that it had filled with water, but was holding. The water-filled center of the tarp was stretched down about 4-5 feet, holding a great deal of water... water that eventually would seep through. Using a garden hose, I siphoned the water out.

The next morning, we set out again, and this time had perfect weather all the way to Minneapolis... unloaded all of our goods, and became citizens of Minneapolis.

Scientific Computers (usually followed by Workman’s Service) was essentially a Tab shop that had recently computerized. They had just acquired one of the first IBM 360’s in the city, a model 30. They still had an IBM 1401 and the school software ran on it. My job was to convert that software to run on the 360, and hopefully, to expand and improve it so that customers could be added. I set out to learn the systems and to learn to program the 360, in BAL (Basic Assembler Language).

SciComp was located in a cramped building, on the 2nd floor, with Workman’s Service ( a temporary agency) on the 1st (now a parking lot). I recall a room full of women working on Comptometers... big old adding machines that had 10 keys for each position of the number... about 100 keys in total. The women entering numbers were like pianists... they used both hands, pressing multiple keys simultaneously... far faster than today’s 10-key adding machines. Upstairs, besides a couple of offices, and the computer room, there was a large area filled with a variety of Tabulating machines. The computer room was naturally on a raised floor, surrounded by glass, and very well air-conditioned... typical for that time. The 360, if you were to have pushed all of the parts together, might have fit in a small bedroom.

Being one of the first and few 360’s in Minneapolis, it was sometimes used for demonstrations by IBM as well as for our own prospects... but became an embarrassment. It seemed that the 360 worked fine until a group of people entered the room for a demonstration... then the whole system would go down. After the people left, disappointed, the 360 system would come back up again. This repeated numerous times, until someone discovered a power cable that was being crimped by additional weight on the raised floor (massive cables ran under the removable flooring... the reason for the raised floor).

I learned BAL, and loved it... it was far more powerful than any language available up to that time... the kind of language an innovative programmer needs... one in which you could find completely different and unexpected means of accomplishing tasks. Naturally, I designed the new school system to be parameterized... one set of programs, with specifications for each school to fit their unique needs. Student Scheduling was one of the school applications... an extremely difficult process... matching student class and hour requests against available classes with limited sizes. It’s a process in which the result is a best-possible set of matches... never completely filling each request. I used a software program we purchased from Stanford University, called Quad-S. It required more “horsepower” than our 360 had, so I ran it at a couple of larger 360 installations... Cargill, in the NorthStar building, and at Northwestern National Life. Even on their larger machines, scheduling a single school could take 4 hours, and sometimes it never finished, being unable to accomplish the desired results. It would simply work on one student until it found a schedule for him... not knowing that the task was impossible by that time. We would have to return the results to the school, with some students just not scheduled at all. At Cargill and NWNL, I worked late at night, in their off-hours, usually quite alone.

Other, and easier, applications for schools included grade reporting, ID cards, etc. Although the experience was valuable, SciComp was a frustrating and boring place to work. The surroundings were depressing, and there was little appreciation of my work. A change took place in upper management... a group of outsiders were installed to take over, and SciComp was set to change significantly... perhaps getting out of the school processing business. Somehow, probably through an advertisement, I made contact with a group called TIES that was being formed to do school processing.

TIES (Total Information for Educational Systems) was a unique, often once-in-a-lifetime opportunities... to build a DP system from the ground up... no old systems to emulate or convert... no specific requirements to meet, except to provide what the users need. The users were a group of school districts in the Twin Cities area, who, together, formed TIES, to provide themselves with computer help. Specific needs were not clearly defined at all, because few people knew what computers could do, or what was practical to have them do. I was hired because of my educational experience, and started in November of 1967... the same day as Jon Nelson... still a friend today, almost 30 years later. We were a handful of people, housed on the top floor of a since-demolished building in St.Paul, at 555 Wabasha... just south of 94. The building had a large 555 on top of it, so many people will remember it. It appeared to have been a minor governmental building at one time. Thomas Campbell, formerly superintendent of Stillwater schools, was the Director, and Jerry Foecke was Asst. Dir.

TIES was organized as a school district, so it was not-for-profit. A large proposal had been written and submitted to get funding, and was successful, allowing the hiring of DP personnel. While at the Wabasha building, we did little except study the overall problem. It was expected that there might be a dozen or more districts joining TIES, and the major questions were:

What needs do they have?

What needs can TIES meet?

What hardware/software configuration to use?

We traveled to member districts, meeting many of the school staff people, from Superintendents on down. Soon we moved to a new facility... a fine one, in Roseville, on County Road B2, between Snelling and 35W. We had individual offices, each with a window, dry-marker boards built into the wall, and a built-in dictation device connected to a central dictation recorder. There was plenty of room for growth (and TIES is still located there). Early on, general areas were assigned, mine being the Student area, and I wrote a survey of user districts to find out what kind of needs they were anticipating. Each of us also formed User Advisory Committees. I chose 7 or 8 individuals, with different roles in their districts, and from a variety of districts, and, over the next year or so, hosted regular meetings with them, trying to identify specific needs. It was a fascinating process. I would emphasize to them that they should assume that we could do anything they could imagine... that they should just wish, but that was so difficult for them, because their knowledge of what, conceptually, was possible, was limited. Primarily, the result was that I got an idea of their problems, and what were not problems, and then used my own creativity.

As we gathered information and shared it with each other, a vision began to take shape... not the same vision for everyone, surely, but ideas began to coalesce. There was a lot of disagreement and discussion about hardware configuration. Should we put some kind of computing power in each school district, or could we centralize it and share it? At that time, communications was pretty primitive... the phone company (still a monopoly) had the legal authority to prevent any device from being used on their phone lines... permission was needed. Telephone communication, the little that was being done, was done via acoustic couplers, a device into which you placed the telephone handset. Telephone lines were quite noisy, had a lot of interferance, and many parts of the phone system still used physical switching devices. In spite of the communications problems, we decided that centralized processing with remote input/output devices in the schools was the right way to go. Putting processors on site had even more drawbacks... there were expensive, maintenance of both hardware and software would be a nightmare, as would training people to run them.

I recall searching far and wide for input and output devices that we could use remotely, and there were few. I met with National Computer Systems, in the old Strutware building, because they manufactured page scanners on which you could mark responses with a pencil. Schools were already used to doing input similar to that. Harlan Ward, President of NCS, was much more interested in showing me his new BIT480 processor... in effect a microcomputer. I met with NEC, a manufacturer, primarily, or large display devices such as you would find used for plant or process control. They were branching out into Cathode Ray Tube technology. I met with their engineer working on CRT... an interesting conversation. He didn’t have a clue about how, or for what, a CRT could be used. With enough time, I could have had him build almost any kind of device I might have wanted... but we didn’t have that much time.

Along the way, we specified the kind of central hardware we would need for this network, wrote an RFP, and sent it to a number of computer manufacturers. In those days, at least in governmental organizations, RFP specifications were usually written, and copied by others, to contain specs that were very favorable to IBM. It was common for other manufacturers to be eliminated from the process simply because they didn’t have precisely what was specified, even though they might have something better. Our primary bidders were IBM, Control Data, Burroughs, and NCR, each of whom sent large written proposals. This was a mid-scale contract, but one that everyone, including the bidders, knew could get a lot of publicity and serve as a model for others.

We studied the proposals carefully. I remember having personally estimated the amount of data that would flow through the network, and using that in my evaluation. The proposals, and the presentations by the manufacturers, were fascinating, and revealed a lot about the companies themselves. NCR was eliminated early... just not having enough beef for the job, and it came down to IBM, Burroughs, and Control Data. IBM put on their typically professional presentation, and you could almost hear them saying ”we’ve got this wired and we know it... you really wouldn’t dare refuse us”. Control Data brought in technical people, and seemed to have put a lot of thought into their specific proposal... an impressive coalition of expertise was what they were offering... they could tailor hardware and software to our specific needs. Burroughs’ presentation was a joke. There was a single salesman there, seemingly unprepared, acting as if he was an orphan who would have to beg or steal to get answers from their center in Paoli, PA.

Luckily, I had worked with Burroughs before, and knew that they were opposite from IBM in that they were very strong on design and manufacturing, and weak in sales. I was convinced that Burroughs had the hardware systems we needed, and would give us the kind of support we needed. I fought hard for that proposal acceptance... and won. Over the next year, we got a lot of special support from Burroughs... and I learned that our inept salesman was a fake... he was not inept at all... that was his sales technique. Once the hardware choices were made... Burroughs central processor, Burroughs remote printers, Motorola remote card scanners, and Burroughs remote CRT’s, we began to get down to specific systems design. My primary areas were Student recordkeeping, Grade reporting, and Scheduling. We hired a consulting company to help define and build a centralized files and communications system... Technalysis. This really was the creation of a major database system, and they did an impressive job. We technical people met together a lot, and wrote a lot, and worked together. We had what we called “shoot-em-down” sessions. Each of us would present a system or procedure... almost any decision we thought we had made... and the group would try to shoot holes in it. It worked great.

Student Scheduling was identified early as a major need. I was sure that there had to be a better way to accomplish that task, and, among other approaches, put together and hosted a meeting in our offices of several of the pioneers in Scheduling, including the designer of the S4 system... Stanford Student Scheduling System, from Stanford University. To be honest, little came from the meeting, except to find that there was nothing newer available, and to perhaps give us a little national publicity.

I was forced to use a system Burroughs found... one that was designed to run on our system. It was impossible to tell in advance whether it would do the job required, and it turned out to be the beginning of the end of my stay at TIES. It took too long to get it up and running, and it didn’t do a very good job of scheduling. That was not unusual for scheduling software, in fact it was the rule. I also ran into an extremely difficult school to schedule, in White Bear Lake. These were the days when modular schools were becoming the rage, and the White Bear Middle school was modular to an extreme... even being a round building, thought to physically fit modular scheduling. A modular schedule had a great many short periods, and each student had a very large number of choices to make. Naturally, that increased the scheduling possibilities and difficulties greatly. The results of our scheduling attempt were attacked, by the TIES representative in White Bear, as inexcusable, and he said so in the school newsletter. I thought his criticism was unfair and should be responded to by the TIES management. They did nothing of the sort, and I began to feel like the fall guy. We were supposed to be a team, doing our best to provide services that had never been available before. We had always anticipated problems would occur because we were breaking so much new ground. Management was silent... the attack went unchallenged... not even commented on, as far as I could see. This bothered me greatly... I had put a lot of very creative, gutsy work into TIES, and it was obvious that Campbell and Foecke were not going to share any responsibility for what was viewed as a failure by one individual. I don’t believe the people in the school were particularly surprised or disappointed at having to do a lot a hand work to get the schedules finished... that was typical for scheduling, particularly for a modular school.

I felt that management had shown it’s real face... that they were going to protect themselves, even if it meant having an employee take the shaft. Essentially, they abandoned me, and their attitude toward me was different from that point on. I might as well have been an outside contractor working there. My end at TIES came when I wrote a very long memo to my fellow technical employees, warning them that what had happened to me could easily happen to them as well... that they would get no support when problems inevitably occurred. Somehow, Campbell and Foecke got a copy of the memo, even though I wrote it in longhand and handed them out personally in envelopes. One day, I was escorted to the front door and told that I could pick up my things later. It was not a surprise, and not a huge disappointment. We said, when we started at TIES, that 2 years there would be enough. The market was good for DP people, and most moved every couple of years.

I’m sure, in retrospect, that I over-reacted. My marriage to Judy was breaking up while I was at TIES, and I was not completely stable emotionally during that time. In my own defense, though, I still believe my original complaint was valid, but I have seen so much of the same kind of ass-protecting management did, in other places... particularly governmental organizations, that I would no longer be surprised by it. The incident would not be treated the same way in most private companies, but Campbell and Foecke were very political people, in a political situation. That’s how they got where they were. Right and wrong have little importance to political people... they are replaced by good for my career and not good for my career. I requested a hearing... a right a public employee has when dismissed, and that was a total waste of time and a great disappointment as well. In front of the TIES board, management was represented by an attorney, who called several of my fellow workers as witnesses against me. The charges by which I was dismissed was failure to submit progress reports... not only unfounded, but not to the point at all. The real issue never came up. They proved that I had been late on progress reports, and that was that. Dismissal upheld. I got no feeling that the board even wanted to hear anything else.

In 1970, Jerry Koch, VP of NCS, hired me. After considerable discussion between Jerry and I, my initial job was to build a formal Systems department. NCS computer activities had been, till then, run by several “old-timer” programmers, primarily Dave Kopishke. These were people skilled at programming the CDC 160-A, with little opportunity to do anything else. Most of the work at NCS involved processing tests and surveys. For each new test or survey, scannable documents were designed and printed, and a set of programs was created to process the data. Each new document had it’s own set of programs, usually just modified from those for a previous document. The result of this process was a large number of programs to maintain, which kept the programming staff busy “putting out fires”.

I knew, and I think Jerry did too, that there was a better, more systematic way of processing data. At the time, we described that method as designing and building “generalized systems”… a single set of programs that used input parameters to tailor its operation specific to each application. The primary advantage of such a system is that, once the generalized system is in operation, programmers are not needed to implement a new specific application.

My major project at NCS was the design, project control and implementation of a single system able to handle all achievement and IQ tests. If this new system were efficient enough, NCS would be able to become a major player in the processing of such tests. NCS’s proprietary documents and document scanners were certainly competitive against other document scanning systems, but they needed to be able to compete against major publishers in scoring, calculation and printing of reports.

Each test differs considerably from others in many ways, and each uses large normative tables. It was necessary for me to understand, in great detail, the proper scoring of a wide variety of test instruments… what similarities and what differences.

The NCS programming staff had grown to include several FORTRAN programmers, and NCS had the use of an old, but large, CDC 1604 mainframe computer for processing. FORTRAN was not a great language for the kind of work we were doing… moving a lot of data around, and producing reports… rather than calculation, which is what the language was designed around.

Frankly, building the “ACH” system was viewed by the programmers as dubious. It was beyond their NCS experience, and they had never worked with a “designer/analyst” before. It was a unique experience; I had no skill in FORTRAN, nor any experience with the 1604… what I was doing was pure generalized design. What I provided to the programmers could have been used with any programming language for any computer system. Although I had been in that situation before, nobody else at NCS had been, and it was viewed as something of a “miracle” to see the system come together. The “parameters” defining a new test were complex enough to actually include a macro language to tell the programs how to process.

Once the programs were defined (7 of them, I believe), I designed general-purpose forms for printing reports, and documented and produced the forms to be filled out in defining a new document. In short, this major and innovative project was a success. NCS was soon a major scorer of many standardized tests. In the process, NCS was transformed into a “systems-oriented” organization rather than a programming environment.

Later, I did a good bit or work analyzing RFP’s for testing programs and survey jobs, determining what our costs would be and helping to write the proposals. Many of these programs were for statewide testing… in Georgia and California, for example.

I also did special projects; one was creating the system, for NSSFNS, to match black students with colleges. That system was, in my opinion, fairly unsuccessful, and should have never been a computer system at all. (See my notes on Bit-Winnow for further explanation).

In my spare time, I became intrigued with a new device, a very early XY recorder… a very general-purpose device that consisted of a large tablet with a cable-attached pen. The pen, when touched to the tablet, emitted a barely audible spark. Two sides of the tablet contained strip microphones that detected the spark from the pen. By measuring the length of delay in the spark reaching the two microphones, the precise location of the pen could be determined. That location, in X/Y coordinates, were output to a punched paper tape device. The tape could then be input to a computer for analysis of what had been done on the tablet. This was an era when inputs to computers were very limited… essentially punched cards and sometimes punched tape. Keyboards were essentially non-existant, as were mouses, since screens were very crude if even available. The XY recorder was certainly the predecessor of today’s graphics tablets, but it could have been used in many other imaginative ways. The concept of doing “posititional” mouse clicks on a computer screen is identical to making pen points on the recorder bed, except that the “display” on the recorder bed could not be changed as a computer screen can be now.

The XY recorder could be acquired with a vertical axis too, making it an XYZ recorder. Some medical researchers were using that configuation to map areas on human heads. One of my delightful associates gave the XY recorder a great nickname: “The Electric Pen that Knows where it’s at”. When I left NCS, the XY recorder was relegated to a dead idea that no longer had an advocate. I wish I had taken it with me.

My (only) 4 years at NCS were great years in many ways… great friendships, many parties, and significant accomplishments. I met and married my second wife while at NCS… she had worked there longer than I, and her mother also worked there for a period of time.

During a recession in 1974, I was laid off. NCS management had changed considerably during my 4 years there, and much of the original management had already left to form a new company, in direct competition with NCS. I would, in future years, still get considerable work from NCS, thanks to old friends still there.

1974 was a tough year in the Smith household. My wife Sandi also got laid off from NCS, and the nation was in a recession. I tried to find work in data processing, but had no success. I was overqualified for all the jobs I found available, and those employers didn’t want to hire someone who was likely to move on when the market got better.

I decided to see if I could earn a living doing artwork or graphic design. I was fortunate to get some work from contacts at NCS, and a couple of other small jobs. My earning were poor, because I had to purchase all needed supplies, and because I had to work extra hard to overcome my inexperience. I also discovered that there were a great many artists willing to work for low wages.

Most of my early work was from NCS, and I got the jobs because I already knew their business. For a great part of the first year, I had steady work on a very large project for the Wisconsin Design for Reading Skills Development, produced by NCS. I created the cartoon character “Word Wizard”, and a general design theme, and then produced hundreds of student worksheets, many box covers, and other materials. I had been working from home, until baby Kira, born in late 1975, began to crawl and make working at home too difficult. I found a small office space on France Ave., in the same building with a chiropractic office and Lonna’s exercise studio. The Word Wizard project was over, and I was left with irregular jobs that didn’t provide much income. During that period, I took a car route delivering newspapers. At that time, carriers had to buy the newspapers, deliver them, and then do collections too, which made it very difficult to even break even. Delivering newspapers was great exercise, but I can say nothing else positive about it. Gradually, my work increased, and I moved to a different office, just west of Highway 100, on Edina Industrial Boulevard. Work for NCS had diminished, and I had to find new clients. I did some illustrations for college textbooks, several advertisements, and began to do some work for Data Decisions, one of several companies spun off from NCS. I began to become involved in the graphic design for a large survey project Data Decisions was doing for General Motors. Eventually, my involvement in that project would lead to full-time employment on it, and the closing of Southpaw Graphicstudio.

My necessary career shift away from computers into graphic design had been successful, but barely. It was six years of survival earnings, and development of some skills that have since been useful, but a new confidence that I could change careers if necessary.

In April of 1981, Data Decisions hired me to work on the General Motors project… combining my graphics skills with project management. I was hired as Director of Operations, primarily to handle GM survey processing. My functions were many… managing programmers to get the processing of data done correctly, designing forms, and creating a clerical production line to assemble, package, and mail the massive number of reports and microfiche to GM offices all over the world.

The GM project was successful, but other projects were few, and it began to become clear that my days were numbered. After just one year at Data Decisions, I reluctantly resigned.

My time as a freelance artist had been quite solitary, and decided that I wanted work that would involve more people contact. Sales was something I hadn’t tried as an occupation, and it was clear that a skilled, hard-working sales person could earn very good income. I took a position as a new agent in the Eng office of John Hancock in Minneapolis, learning to do financial planning and to sell life and disability insurance. After studying, I took the state test for licensing as an agent, and as a registered representative, to sell mutual funds. Hancock had a formal two-interview system for analyzing needs – gathering information in the first meeting, then returning with specific proposals and trying to sell appropriate products to solve the needs.

There were aspects of life insurance that I found fascinating – the variety of kinds of policies, the advantages and disadvantages of each – and the analysis of a prospect’s financial needs toward finding solutions.

The system was well-designed, not designed to trick or inflate sales, but to identify real needs that could be well-solved by insurance products. Hancock products were quite competitive, and the company had a long and excellent reputation.

Once reasonably well-prepared to handle interviews, our primary task became getting interviews. Phone calls were made to some existing policyholders whose original agent was no longer around (called orphan policyholders) to review their situation in hopes of making new sales.

However, we spent most of our time “cold-calling” people from the phone book. This is extremely frustrating work, with poor results. Most people simply didn’t want to talk at all. The system is based on historical results… if you call enough people, you’ll talk to a number of them, a small percentage will agree to meet with you, and few of those will buy something.

The fact is that most people do not want to even think about insurance, which is a precaution to repair damage from a personal catastrophe such as death or disability… real but unpleasant considerations. It requires real skill to get a prospect to consider those contingencies and then to spend money to cover them. It’s an intangible product that gives no pleasure to the buyer except the knowledge that they’ve taken a step to insure that their financial plans will be protected.

I had no problem with insurance as a product that is a worthy purchase. What I did have a problem with was pressing the prospect to choose to spend money on it instead of on other things. I understood that that is the prospect’s decision to make, but I couldn’t present it with enough enthusiasm. There are many ways to spend ones earnings; insurance is generally considered a wise safeguard measure, that I couldn’t press as a real need for most people I worked with. It wasn’t that selling the product would do any harm, but rather knowing that it might not be the wisest expenditure for the individual. If someone had already decided to buy insurance, I could have been an effective salesperson, but with insurance that is rarely the case; most of the sales is convincing the person that they should have insurance.

I struggled hard to do the job, and, frankly, had poor results… even compared with other inexperienced agents. Remarkably, I became party to a joke in sales: if you can’t sell, train others to sell… and I became a training supervisor of new agents.

I enjoyed the training process, but supervising new agents was a heart-breaking job. The number of new agents who have reasonable success is extremely low. Sales is a task that appears to be routine but isn’t, and admitting failure is a long, drawn-out, painful process. New agents work days trying to get appointments, and evenings in order to meet with prospects, which puts a strain on their own personal lives. In retrospect, it has become obvious to me that I had never failed at anything prior to going into insurance sales. I was in my early 40’s, and believed that I could successfully do any job I set my mind to. Admitting that this was work I was not good at was not easy to accept.

About the only positive aspects of my time with Hancock were several trips to the Boston headquarters for training, and becoming involved with a major shift in the use of computers. While I was at the agency, Hancock implemented a nationwide online network that allowed our agency to access computerized policy records from the main computers in Boston. Very soon after that, personal computers came into being, and I became involved in investigating how we might be able to use them.

When personal computers first became available, nobody really knew what they could be used for… there were no specific applications in existence, and very little general-purpose software to work with. Because of my experience, I could envision how PC’s could revolutionize many tasks, but trying to pass that vision along to others was extremely difficult… that which needed to be done was being done… manually. I tried repeatedly to promote my vision to a “big-hitter”, a very successful agent in our agency, and his response said it all… “Why would I want a PC when I’ve got Eleanor?” (Eleanor was an old-time, experienced clerical person, who knew the insurance business well).

As it turned out, I got my opportunity to prove my vision to the big hitter when he decided to put together his own office and staff, and physically separate himself from the Hancock agency. He (Rollie Martin) hired me and a couple of other people, and took office space just down the hall… formed Martin Financial, and soon after bought a PC.

In April of 1983, I began working for Martin Financial Services, Rollie Martin’s firm. Our new offices were on the same floor as the John Hancock agency, at 3033 Excelsior Blvd, between Lake Calhoun and Lake street. Martin was one of Hancock’s leading agents nationwide, but Hancock agents were technically independent, rather than “captive” agents, meaning they were free to sell products of other companys. Rather quickly, Rollie and I began to think of ourselves as Mr. Outside and Mr. Inside… he met with clients, made sales, and I did the support work in the office, preparing proposals and handling many other details. Rollie acquired our first PC, an IBM portable PC, and I began to produce capabilities we could use in increasing sales of life, disability, and group medical insurance.

Very little software was available at that time, but Lotus 1-2-3 was perhaps the most significant, and I became extremely proficient using it to produce complex proposals and even basic database files. Soon, real database software became available; dBase was the most widely used, but I discovered a superior product, Revelation, from Cosmos, and began using that.

My task was to insure that Martin could concentrate only on sales, which was his great strength, and be assured that all other details would be well accomplished. I would handle a particular area until there was enough volume to justify hiring someone specifically for that area, then I would train that person to handle it. We did that successfully and quickly, soon having quite a significant staff of specialists. MFS became extremely successful, and Martin was named Hancock’s top agent. To celebrate, Martin took a number of us to Hawaii for a week. Our return flight was as memorable as the vacation itself. Minneapolis had a huge (even by Minnesota standards) snowstorm as we returned, and the airport was closed (an event that very seldom occurs). We were held up in a transient terminal for many hours in L.A. before returning, then had to face deep snow with the light clothing we had taken to Hawaii.

I should add that during that first year, my marriage ended in divorce.

Not long after, Martin acquired new, larger office space in St. Louis Park, on the 9th floor of a building overlooking Highway 12. By that time, MFS had grown to around 10 employees. As our jack-of-all-trades, I designed the office layout – nine individual offices and a couple of common spaces, one of which was, significantly, a computer room… significant because I had succeeded in convincing Martin that computerization would allow us to grow and prosper. Indeed, we purchased a PC for each employee, and I set up an early Novell network for our whole operation. By that time, I knew all aspects of the insurance business well, and designed and programmed a grand database system to integrate all aspects of it. The system was successful enough that 2 people were sent to study it from the John Hancock home office in Boston, as a possible model for other agencies.

My years there were both great and horrible; great because we were a smooth and successful operation, and horrible because, as we grew, Martin changed. Our strength had been our flexibility, our cross-training, and our ability to work together, all traits I had worked hard to achieve. At some point, Martin began to think of himself as CEO of a corporation, in the worst sense. I had great respect for his business judgement, and his intuitive knowledge of what would work and what wouldn’t, but he began to implement “policies” and restrictions, and to treat the employees as replaceable resources rather than as people. Innovations I’m proud of pushing into MFS include employee profit-sharing, and treating vacation, sick days, etc. together, so that employees who didn’t get “sick” could take that time as vacation. Eventually, the atmosphere became political, stilted, with employees afraid to speak their minds (except me, naturally). In time, I pushed hard enough to cause Martin and I to part ways.

I recall having Martin once tell me that one of his secrets to success was in dealing with companies small enough that one man could make a decision. That is a great strength of small businesses – too bad Martin couldn’t keep himself in that category.

When I left Martin, I vowed to never again be an employee… and I haven’t (except for one brief 6-month stint as a near-employee contractor).

Before leaving Martin Financial, I had been fortunate to have purchased a house, at 5608 James Ave S., so this chapter unfurls from that location. I was determined to become self-employed.

Windows was still quite new, and many corporations were in the initial process of purchasing desktop PC’s for their employees… often just delivering the PC to their desk and hoping the employee would figure out how to use it. At that time, the IT departments, who didn’t even like the idea of employees having PC’s, controlled corporation data processing. They knew that they would be called on with lots of questions and problems. They had already had problems with some employees who purchased their own PC’s.

It was a marvelous and confusing time… with employee end-users determined to personally make use of computers, avoiding the long waits involved in requesting information from IT. Employees of all sorts were digging into PC software, and creating innovative solutions to real business problems. Very quickly, those same employees wanted access to all the data the IT department had stored on their large computers… they wanted to analyze it themselves. There were plenty of problems; inexperienced users, developing quickly and part-time, and adopting bootleg software from other users. Windows itself came with included tools that were useful problem-solvers, if only the user could master them (while doing their regular job).

I decided to first become expert in the use of Windows, and began studying, experimenting, and reading all I could about Windows itself. I found that by carefully documenting what I was learning, it really began to clarify… much like the old saw that there is no better way to learn something than to try to teach it to someone else. Soon, I was developing a Windows learning course, initially for my own use.

During that same period, I decided that I wanted to try to become expert in Microsoft’s new Access product. My daughter gifted me with a copy of Access at its initial release price of $99, and I began to study the manuals and work with the software.

Access was, more than most software, very graphical rather than programmatic, and it was also deceiving, being more complex than it initially appears. It was extremely easy to do simple tasks, but most users would quickly find themselves unsatisfied with what was easy to do. Since Access was sold for only $99, in retail stores, many people purchased it and soon found themselves becoming far more technical than they intended, and even at a loss as to accomplishing what they set out to do.

As I became proficient in Access, I was looking for contract work using it, and having no success at all. One reason was that corporations considered Access a “toy” software product, designed for home use, not for business use. It wasn’t true, but corporations simply will not take $99 software seriously. Another reason I couldn’t get Access work was the old catch-22 that we won’t hire you unless you have previous experience… and I couldn’t get that first job.

I switched tacks, and took a temporary job teaching Windows at Minneapolis Technical College, in the evening. I convinced them to let me use my own Windows course, and MTS duplicated it and placed it in the school materials store. The teaching paid about $20 per teaching hour. Considering all of the additional work outside of class, the actual hourly rate was considerably lower, but it was work, and I was teaching a class of about 20 people. Some were MTS full-time students taking the course for credit, but most were either individuals wanting to learn how to take advantage of their own computer, or employees who wanted to learn how to use the PC their employer had “dumped” on them.

I found such teaching exciting. Every “Oh! I get it!” from a student could translate into seriously practical results when they got back to their own PC’s, so the learning was extremely valuable to them. It was harder work than I anticipated, because it was so important to the students. Each was impatient to learn quickly, so I had to move them as quickly as possible without losing anyone. Fortunately, my material allowed a good deal of experimentation along the way, so the brightest could be satisfied while slower students caught up.

MTC was well-equipped for such teaching, with a couple of large lab rooms filled with PC’s. While I was teaching there, MTC, in search of more state money, doubled the credit for my course, and doubled the length of the course hours. I was effectively teaching Windows in X classroom hours, now I was to spend 2X hours covering the same material. There simply was no more of Windows to teach, so I began teaching other software that happened to be on the same PC’s… whatever I could find, to pad out the course. I even taught the basic concepts of database work.

I began adding more teaching jobs, at suburban Adult Education centers, in Edina, Hopkins, Bloomington, and Richfield. In Richfield, there were no PC’s, even for demonstration, so I arranged to roll one of their administrative PC’s into a classroom to at least demonstrate. The other school systems had good PC labs already established. In the case of Edina and Hopkins, they were quite luxurious, with all new, powerful PC’s.

Teaching Windows somehow made me a PC “expert”. I was… not because of the teaching, but it seemed to qualify me for other work. It made my resume’ reputable.

This was the beginning of a period when businesses were cutting back on employee cost and hiring contract workers in great numbers. I answered an ad for Revelation work (Revelation was the database software I had used at Martin Financial) at Delta Dental. Although Revelation was never widely used, those companies who used it often built their business around it. Delta Dental was such a company. They had a massive Revelation system that handled their most important data. By that time, the manufacturer was barely supporting the original DOS versions of Revelation, because they were developing Windows versions, which were, naturally, quite different and difficult to upgrade to from the old versions. Delta had already decided to upgrade their systems to Oracle, and I went there for what was to be a 2-month contract to make some changes. I ended up staying 4 years, close to full-time for most of that period. Upgrading to Oracle turned out to be far more difficult than they assumed. One regime in the IT department was tossed out during that time, for having been so wrong about the difficulty.

I became the resident Revelation guru at Delta. There were several employees who had become quite proficient with the software, and had written quite a bit of it, but these employees always had regular work to do in addition. I made major changes to their systems, and even added new systems, since Oracle was still not a reality. Over time, I became virtually indispensable to Delta. I recommended that they assign one or two employees to do only Rev work, so that they wouldn’t be so stupidly dependent on me, but they never really did that. It was an IT “thing”… only “professionals” will work on our systems, not employees who happen to know how… even if they wrote the systems in the first place. Over that 4-year period, I watch almost all of the IT department turnover, including the department head. It was a crazy place to work, but their dependance on me insulated me from the results of internal politics. Twice I left in anger and was begged back with an increase in hourly rate.

Eventually, the Oracle systems began to come on line. When I finally didn’t want to work there any longer, at any reasonable price, there were still key Revelation systems that hadn’t been replaced, and I got calls from employees for another couple of years. I knew that Revelation was dead-end work, and they didn’t want to pay me $100/hour, so the calls finally stopped.

I had begun getting contract work in Access, at Lutheran Brotherhood, Norwest Bank, and had even taught an Access class, using my own materials, at a plastics company in Bloomington… and taught briefly at Computer U, near the Amtrak depot in St. Paul.

By that time, Access had become in demand, thanks to brilliant strategy by Microsoft. They had improved the product, and raised the prices to make corporations feel good about buying it. Pressure from individual employees who like Access also played a role in finally getting IT departments to view it as a “real” piece of software. More importantly, Microsoft, with great end-user (developer) support, had created a sizable number of people like me, with Access development capability. In other words, they had created a body of contractors available to do development work. Corporations could find people like me when they couldn’t find contractors skilled in other, competing software. I cannot emphasize too strongly the masterful strategy of Microsoft. While developers like me had to beg and search for help from other manufacturers, Microsoft gave us free and easily available tips and training in Access (and other products). They made it easy for us to become skilled developers in their product… thus creating a workforce that made it easy to sell their products in the corporate market.

All of the contract work I had in Access was fixing, improving, or replacing systems that had been poorly developed by non-specialists in Access… often, again, by employees who just built the systems in their spare time, or by mainframe programmers who just didn’t “get” the value of PC’s.

A prime example of the latter was a system at 3M. (For a brief 6 months, Keane, a large consulting firm, employed me to do Access projects). In my work with Access, I quickly discovered that writing code should be a last resort… that queries could usually replace code and run much faster. That was a “secret of success” for me. The system at 3M, for example, was almost all code, and it seemed terribly slow to me. I convinced 3M (I was working for one of my former students ) that I should replace all the code I could. Working at home, I laboriously discovered what the massive amounts of code were doing, and replaced a lot of it with queries. The resulting application took half the time to run. In fact, it was so good that my employer wasn’t happy… it turned out that the original code had been produced by another of their contractors, and my work made their original job look shabby.

I was moved to two more contracts by Keane, at Lutheran Brotherhood. One was to clean up and document a system written by one of their investment brokers… the other to replace an Excel application written by another employee. By that time, I was fairly fed up with the politics of Keane. In conversation with them, I mentioned that I was still doing some work for Delta Dental in evenings. I thought they already knew that, but having it in the “open” violated their policies (even though most employees were moonlighting too). They asked me to drop Delta and I refused, and that was the end of my relationship with Keane… and I returned to self-employment. I did get some dental work done free while I was a Keane employee, and it did reaffirm that I didn’t want to work as an employee.

I had a small variety of other contracts after that, at Norwest Bank, and back at 3M (not with Keane). The best part of those contracts was the willingness of major corporations to trust me to work at home. In reading through the want ads one Sunday, I saw this tiny ad looking for Access help. In retrospect, I’m surprised I even noticed it, given the large number of big ads for computer people at that time. I phoned about the ad, and went to speak to the owner of a 2-man company in Eagan, named Shipping Solutions.

Again, an old story repeated: His single employee had developed an Access system to help them do import and export… to produce the many documents needed for government, shippers, etc. Their original software had been so useful that others wanted it, and they soon were selling software instead of doing import/export themselves. The software worked, but it was developed in a strange way that made it very difficult to expand and improve. Remember, it too was developed by an untrained employee as part of his regular job. Thus began a good long relationship. I learned the existing system, the original creator left for greener pastures, and I supported the existing version. Much of the early work was customizing the software for individual customers. Over time, the owner and I, through many conversations, concluded that a rewrite was called for, upgrading to a newer version of Access. To be blunt, the two of us working together defined a greatly superior version that has since become the most widely used in the industry. Again, pricing the new version considerably higher was also a key to success… causing larger companies to consider it a “serious” product.

Shipping Solutions became a “hit” product, and we made frequent upgrades to it, producing still more sales. After several years of this success, I was still working on an as-needed contract basis, at $60/hour, and working very nearly full-time. The owner offered me a full-time employee position, at good pay but less than I had been making. Because peripheral benefits have never been important to me, and because I would have been working on site rather than at home, and because I was deeply involved in volunteer work for the Libertarian Party, I declined his offer. He hired another contracter for the full-time position. Since that time, my work has diminished steadily and by now to almost nothing. Being wrapped up in volunteer work, I neglected to seek other contract work until it was really too late… until we were in the throes of a recession, and similar work had become almost impossible to find.

As I write this, in July 2002, it is probably the end of Solutions by Smith. That’s not sad for me… I look forward to doing different work, and it certainly won’t be my first career change. Computer work has been a good income source for me over several decades, but I long ago grew weary of it… the intricate detail, the need for extreme care, and the isolation from others. I think of it as lucrative, unpleasant work, so I’m not likely to miss it.