A Keypunch
The tools we use to craft software have changed radically since my first job, but the art remains much the same.
Today it is not unusual for a 26 year old to hire and lead a team of programmers. In 1965 it was very unusual, but that is just what I did early in my career. After graduate school I joined Bell Labs. My first job, working on the Nike antiballistic missile system, turned out to be very boring. I convinced my management that the Nike programmers needed a time-sharing system (TSS) and that I should lead a team to build one. I talk about this in some detail in my previous post.
In the 1960s most people had never even seen a computer, much less used one. Computers were very expensive and tightly scheduled. The cost of an hour of computer time was more than it costs now to buy a laptop. Even programmers usually did not get to touch the computer. Debugging was done by submitting your program (on a deck of punched cards) to the computer operator and waiting, often for 24 hours or more, for the results to be returned to you. If we were to build a TSS, though, we would need hands-on access to a large computer for hours at a time, a very expensive and unusual procedure. We were authorized to use a GE 635 computer scheduled to arrive soon at our Bell Labs location, Whippany.
Imagine what it was like to write software in 1965. No keyboard or screen on you desk; just a pencil, a pad of paper, reference documents, and a cup of coffee. The language we used was the GE 635 assembly language (very primitive by modern standards). Once you had your program written down, you took it to a keypunch machine (like a weird desk-sized typewriter that typed holes in cards instead of typing onto paper) and typed it onto cards, one punched card per line of code. Then your punched cards, along with the punched cards from the other team members, were taken to the computer and read into it to test the program.
Woe betide anyone who dropped or otherwise shuffled their card deck. They’d probably have to start over from their handwritten coding forms. We quickly learned that after punching our cards we should feed the card deck back into the keypunch, running in duplicator mode, to create a copy of the deck, in case the original got scrambled or damaged.
When we started building our TSS the GE 635 computer had not yet arrived. We obtained permission to use the GE 635 at MIT (which, like the Whippany one, was purchased for use with MULTICS). So every day at work we would prepare our card decks, and by 5 PM put them in card trays. Each night two of us (on a rotating schedule) would take the redeye flight to Boston (our equivalent of the internet), run the card decks on the MIT computer, and fly back. When the rest of us came to work the next morning the results of the computer run would be available. So, we got overnight turnaround from New Jersey on the MIT computer, which was much better than the 24-48 hour turnaround I used to get as a graduate student at MIT.
Once the GE 635 arrived at Whippany we had hands-on access to it, but only at night. So every day after supper we would all spend much of the night on the computer. Even though we had hands-on access, the debugging process was very different from today. Because we were building a TSS we had typewriter-like terminals (keyboard plus printer) attached to the computer, but these could not be used to modify the TSS software itself. So the debugging process was: read in the punched cards containing the software, run and test the TSS, find a bug, go to the keypunch room next door to correct the software, read in the corrected cards, and repeat.
Because of the Nike TSS we built, then MULTICS, and then UNIX, this project was the last time I ever had to use punched cards.
We worked long hours and very much enjoyed our work. It was a wonderful job, working with my team with very little supervision, building an exciting, state-of-the-art system. Back then there were no software startups, but our project, was much like one of today’s startups with the added advantage of being paid a good salary.
The tools, language, and procedures we used to write and debug our programs in 1965 were radically different from those we use today. Back then neither we nor even the most far-out science fiction writers could imagine what the world of computers would become. None the less, the art of programming, the intellectual process I used then in crafting software, is essentially the same as I use today in building modern, cloud-based software.
In my next post I’ll talk more about the Nike TSS project and how it resulted in my involvement with MULTICS and then UNIX.
– Rudd Canaday (ruddcanaday.com)
– Start of blog: My adventures in software
– Previous post: Boring Software Job Becomes Bold Adventure
– Next post: How I Beat and Joined MULTICS
Share this post: data-url=””
data-via=”ruddcanaday”
data-text=””
data-count=”none”>Tweet