First, I need to say that this is not a page about skiing! I’m using my Retro-Ski site to get started on another project and I don’t want to invest in a new URL/website until I know if I’m serious about it!

This will be my memories of being part of the early days of computer programming or software development. I’m not sure I can say I was part of the infancy of programming, but I was definitely part of the adolescent stage of the discipline. Now there are some out there who will say that it’s still in its adolescent stage, sort of an unruly teenage, but there are signs of some maturity.

“The Bleeding Edge” was a phrase I’ve stolen from a fellow programmer, Mike Rubin. It’s a play on the term “Leading Edge” and it did seem in those days we were always being asked to provide “Leading Edge” software and on impossible schedules! By the way, Mike was one of what I called the “55X” group. I’m not going to explain that term until much later so you’ll have to be patient.

Just to give some idea of the timeframe I’ll be covering, my story will start in 1964 when I graduated from high school and run into the early 1980s. In other words, the mainframe era of computing. In my career, I worked as a programmer for IBM from 1968 until 1999. Then I taught Computer Science at Saint Michaels College in Vermont for 11 years.

Why do I want to write about this? My memory is still good and I have a lot of memories – fond and otherwise – of my early years programming computers. I’m 76 and as I see more and more of my age group developing memory problems, I am motivated to get my memories documented. I wish I thought that these have profound values for younger people or future generations, but I doubt it. However one thing I have learned in my writing about personal memories of skiing is that other people like having their memory jogged to recall similar events. So here we go on a trip down memory lane!

The Beginning….

I graduated from Kennett High School in Conway, New Hampshire, in June of 1964. I had been good at mathematics and even won the math award for my graduating class. So it was sort of no-brainer that I majored in math upon entering the University of New Hampshire in the Fall. Coached by my guidance counselor, George Davidson, I chose to enroll in the School of Technology math program as opposed to the Liberal Arts. The first couple of years in the Technology math would involve the same courses as the various engineering majors such as Electrical, Mechanical, Civil, and even Chemical. So if I discovered something that interested me more than just the math, I could easily change majors. Note that there weren’t majors in Computer Science or Computer Engineering in those days!

I have to add that while I had heard of computers, I knew nothing about how they worked or the concept of programming.

By enrolling in the Technology curriculum almost all my courses were “required” and I only had one “elective” course for my freshman year. This was actually a blessing since I was pre-enrolled in all my classes while liberal arts students faced the challenge of putting together a schedule of courses and sections. Today that’s all handled by, you guessed it, computers! But in those days it was a hectic physical process held in the field house with students rushing around to see what course sections were available and building a schedule on-the-fly!

One of the required courses for my first year was an Introduction to Engineering course. During that semester each of the engineering disciplines would have a segment to give students an idea of the types of problems and solutions the discipline could involve. However the first part of the course was a quick introduction to FORTRAN and writing a program. The assignment was just a very simple program that would read two numbers on a punched card, add them and print the result. Or something like that. But in the process of doing the simple program we were exposed to the computing center, how to keypunch our program, how to submit it to be run, where to pick up the printout, etc… I’m also sure we were exposed to keypunching errors, syntax errors, and probably even debugging the simple program!

An aside at this point: The UNH computing center had an IBM S/360. I’m not sure of the model, but it would have been state-of-the-art for that time! It also had an older IBM 1620 with which I would become intimately familiar! It was a hands-on computer versus the S/360 which was operated by staff. When I was interviewing for jobs four years later everyone was showing off and bragging about their S/360s. Everyone, that is, except IBM!! Internally they were still working with the old 1400 series. When I interviewed with them they were saying they hoped to have their S/360s in 6 months! I would learn IBM was an embodiment of “the cobbler’s children have no shoes!” That would eventually change, but not for quite a few years.

I wish I could say the ten line FORTRAN program was my epiphany moment and I immediately knew how I wanted to spend my 40+ year career. However that was not the case! It would take some other fortuitous opportunities for that revelation.

The first occurred when I got a summer job after my sophomore year as an Actuarial student at Union Mutual Life Insurance Company in Portland, Maine. The potential job had been announced in one of my math classes and while I had no idea what an Actuary was, the $85/week pay attracted my attention. Today an $85/week summer job doesn’t sound like much, but in 1966 it was significant. Somehow I got one of the four positions. There were two RPI students, one from the University of Maine, and myself.

The job consisted of administrative work in various departments plus daily classes to prepare us for the actuarial exams and provide an overview of the insurance business. Union Mutual was an old insurance company founded in 1848. The company could brag about a couple of “firsts”, the first to reinsure another insurance company and in 1924 the first to offer group insurance. That latter development was a big deal in the 1960s. Companies were competing for employees in a booming economy and looking for benefits to augment salaries to attract applicants. The group department was booming while the individual insurance department was idling along.

The first part of that summer I worked in group insurance computing rates for potential companies. It was very busy! I worked in large open office area, the prototype scene for that era with low partitions separating rows of desks. In this case, each desk had one of the old electro-mechanical calculators made by either Friden or Marchant. Most of the desks were staffed by young women which was sort of an extra job perk for me as a summer student. As I mentioned, there was lots of work to be done and the staff was energized and effective.

The second part of the summer I worked in the individual life department. While the layout was similar to the group area, the tone and pace were completely different. It felt like a library where you had to whisper. The staff was again mostly women, but older women. And the amount of work actually meant that most of the women had finished their daily work before the 4:30 end-of-workday. They would clean their desks off and politely wait for 4:30 to leave.

On that last point, I just have to share one of my obnoxious college summer student habits. My calculator was a Friden. I think that was the one with a carriage that moved left to right when doing division with lots of whirring and mechanical noise. When I had some time to kill at the end of the day, I’d enter 999,999,999,999 and divide by 1. Then watch as all the women just waiting for 4:30 would look at me with disgust.

Notice that I don’t mention computers in any of my work. But actually part of my work in the individual life department indirectly involved a computer. The company was computerizing its individual life policy data which meant a huge data entry project. No, we didn’t have to keypunch the policy data, but we did have to go through giant binders of computer printouts to find the errors!

Fast forward to the following summer when I returned to Union Mutual. At one of our welcome back sessions one of the young actuaries asked if anyone knew FORTRAN. My hand shot up in typical overconfident college student fashion!

Union Mutual was just starting to get into the group pension business and wanted to computerize the process. So the job fell to the young actuary and me!! He had only slightly more FORTRAN experience than I did and no one else at the company had any (their programming was in Autocoder, I believe.)

I may have been a little premature in my confidence about knowing FORTRAN, but by the end of that summer I knew FORTRAN!! And I knew what I wanted to do after college! I wanted to be a programmer!

Just to provide more detail on what we computerized. A company interested in a group pension would submit employee data (age, years of service, salary) and select a particular plan. The data would go on 3×5 cards which would be processed by those human calculators I mentioned before and a quote would be prepared for the company. If the company wanted to change the plan options and get another quote, it would be back to the hand calculators. Depending on the size of the company the turnaround time could be weeks. Plus if the group pension business took off, there would be a need to hire a lot of those “hand calculator” people!

Our goal was to write a system that would get the employee data on punched cards to be input to the computer. Then a program could do the calculations based on the options. Any change in the options would only require rerunning the program. A process that previously took weeks could be done overnight!

We designed the punch card format for the employee data and the forms used to instruct keypunch in creating them. We worked on an output format that could provide the equivalent detail to the manual process. We even worked on the legal contract that would be used to officially sign up the company. That last one wasn’t computerized, but I include it to show the scope of work my summer project entailed. And we got a good start on implementation before I had to leave at the end of the summer. In the process I learned about the limits of computers at the time.

We were programming for IBM 1400 series computers which had 8K words of memory as I recall. That would be 32K in today’s memory units. So we had to learn overlay structures, storage media and FORTRAN I/O. I also learned the sometimes frustrating process of batch processing. They would only run our programs overnight so if you made a stupid error, it cost you a day. This was a very good lesson to learn early in my programming career!

An aside here: During that second summer I witnessed something whose importance I would later realize. Union Mutual was upgrading its computer hardware and chose an RCA Spectra 70 over an IBM S/360. Both companies claimed their computers could run old IBM 1400 series code in emulation mode and faster than it ran on the 1400s! However once the Spectra 70 was up and running it had difficulty even running the 1400 code. Union Mutual decided it had made a mistake and asked IBM for a S/360. In a matter of days the IBM field engineers arrived to install a new S/360. They didn’t even wait for RCA to remove the Spectra. The IBM engineers disconnected the RCA equipment and wheeled it into the hall while installing the new IBM hardware. We had to walk around the Spectra sitting in the hall! In those days the backlog to get an IBM S/360 was at least 6 months, maybe a year. Shortly after I joined IBM the U.S. Government brought an antitrust lawsuit against IBM! One of the accusations was that IBM showed favoritism in handling delivery schedules. When a competitor’s hardware was being replaced, IBM would expedite delivery. Hmmm, sounds like I witnessed a prime example of that!

Before I leave the topic of Union Mutual. The company changed its name to Unum in 1986. It is now an International company and claims that one out of three Fortune 500 businesses use its products. Unum itself is #266 on the Fortune 500 list!

Also, I feel I should add that I did not pass the first actuarial test which was another indicator that my career should probably be in a different direction. I have great respect for those who do pass the actuarial tests, particularly the tests that you take after you begin your career as an actuary. When you’re working full time and have to find time to study for the exams, it’s challenging! I saw the pressure that some of the actuaries at Union Mutual felt as the exams got closer.

Once back at UNH for my senior year I immediately looked into what computer courses were available. There was one! It was a numerical methods and computers class which I signed up for.

The course was taught by Professor Shan S. Kuo and we were to use the textbook he wrote. One thing I learned in college was it was never a good sign when professors used their own textbooks (or one written by the department chair!)

There was a communication problem partly due to language as Professor Kuo had a strong accent. This may have contributed to rather confusing wording on problems. On one particular exam he included a question for which he had not provided enough information to actually solve the problem. Some of us including me didn’t recognize that and struggled on burning up valuable time. For that, I would receive partial credit. Some students recognized the lack of necessary data and basically stated that fact as the answer. They got zero points! When one of them pointed this out to the Professor his answer was, “I want you make assumption.” Sure he did!

I remember another Kuo-ism after an exam where he said, “Marks range from very high, 100, to very low., zero, for example!”

However I did learn more about computers including an introduction to S/360 Assembler language. I didn’t truly appreciate what I learned about Assembler until I went to work at IBM.

I also got a lot of time on that IBM 1620 I mentioned earlier. It was a hands-on computer, no operator involved. And punch cards were the input of choice whether for FORTRAN source code or data for the program. Even the compiler was on punch cards! To compile you grabbed the compiler deck of about 1000 cards, placed it in the card reader, put your FORTRAN source deck on top of it and pushed LOAD. Assuming you had no compilation errors, an object deck would be punched on cards. Then you would take a Loader deck which was much smaller than the compiler, put it in the reader, followed by your object deck, followed by any data cards the program would be reading, and push LOAD. If you had subroutines, additional steps were required.

I’ll be talking more about the world of punched cards later, but here I’ll just mention punched cards that repeatedly were put through a reader were more likely to jam. So the UNH computing staff always had multiple copies of those compiler decks available just in case.

In addition to writing programs for the course, I also made some money writing programs for other students in other classes. By then more courses were trying to introduce students to computers and even students in the business school needed some simple programs.