Why? Well, if writing computer systems today is like moving cross-country in a Mayflower moving van, then writing them in 1970 was like making the same move in Volkswagen Beetle. The second generation machines like the 1401 and 1410 had anywhere from 4k to 32k of memory and the early 360s weren't much better. This is "k" now, not Terrabytes, not Gigabytes, not even Megabytes, but Kilobytes! My current laptop PC has 160 mg of memory which makes it about 32,000 times larger on the inside than the company mainframes we were using then. And what programs were being written? Storing a few recipes maybe? A ToDo list? The projects I remember working on in that era were an Open Order system and a Sales Commissions System for a manufacturer, and a Central Database System and a Funds Transfer System for a bank. Big systems on computers that were of microscopic size compared to today's behemoths.

So how do you make that cross-country move in your VW Beetle? The basic method was something called overlays. Since there was no way to put your entire program plus needed data records in the available memory, you divided your program into chunks (overlays), brought in one chunk, and started executing it. When it needed some code that wasn't in memory, you read in a different chunk from disk storage. Of course, that was an additional I/O, and your program -- which was glacially slow by today's standards anyway -- slowed down even more. Still belaboring the Beetle analogy, it's like moving from New York to California by driving back-and-forth with one Beetlefull of stuff each time.

When you're in that situation, you begin by throwing out everything that isn't absolutely necessary. Did I say everything? I meant EVERYTHING! We didn't have bloat-ware, we had anorexia-ware. A common practice, for instance, was to recompile programs for no other reason than to make them smaller, and I don't mean cut their size in half, I mean cut out 100 bytes or so. Maybe that small amount would mean that the program could run in nine overlays instead of ten and that, in turn, might cut an hour off the run time. The company I was working for gave me an award for doing something like that (I don't remember exactly what I did).

During this period, a lot of programming was done in assembler languages -- BAL for the 360s and something called Autocoder for the 1410s and 1401s -- and, unlike today using high-level languages, it was easy to see how many bytes of storage a particular piece of code used. This produced a competitive environment to see who could create the tightest code. A bit like the TV game show Name That Tune, "I can code that routine in 152 bytes." "Really, well I can code it in 141 bytes." Some atrocities were committed in the name of tight code that make me cringe 30 years later. Some of the early machines didn't have a distinction between code space and data space where code space was read-only. There was just memory. The result of this was that you could write a program that modified its own instructions as it ran. Instead of storing a value, retrieving it later, and using it, you could just store it directly in the instruction that was going to use it, eliminating both the storage area and the retrieval instruction. This had the charming effect that you might be trying to figure out a problem by looking at a program listing that didn't match the program that was running in the computer.

There was another space-crunch in that era as well that, in the long run, may have been more important than the size of the computers. It was the size of the input medium -- the 80 column punched card. Eighty columns isn't much if you're trying to enter a purchase order or a shipping notice or a new customer, and using multiple cards for a single transaction caused its own set of problems, so anything you could do to squeeze a transaction's worth of data into a smaller space was fair game. Using a four-digit date on a punched card would have been regarded as just silly. Those eighty-character cards were read into computers where they turned into eighty-character disk or tape records, and those eighty-character disk and tape records stayed around long after punched cards went the way of the dodo and the passenger pigeon. Well into the eighties (er...1980s, that is), every time you took a look into a new program you'd see an eighty character record and every block size on tape was a multiple of eighty. Eventually the evolution of hierarchal and SQL data bases eliminated most of the eighty character records, those databases were so different that the whole concept of record length became a bit nebulous, but even in its final death throes, the 80 column punched card managed to fling a good many of its two-digit years into the new medium.

Anyway, back in 1970, in this environment, would you stick 30 or 40 bytes worth of 19s that were basically constants into your data records? No way. And that was the right decision for that time. The problem came later.

"Well, that's a good idea and it's something we definitely have to address, but this year the budget is so tight I just don't see how we can squeeze it in. I'll try to get it on the docket for next year, but you know how upper management is about these infrastructure improvements. They like visible results."
[Wait one year.]
[Is it 1997?]
[If no, loop back to label]

"Oh, my God! How did this happen? We'll never get all this work done in time."

It doesn't surprise me that Y2K worked out the way it did. In these last few years of the millennium Y2K is a glamour project with lots of media attention and scrutiny, but if you go back in time even a few years, Y2K was the exact opposite of a glamour project, it was an infrastructure project. The problem with infrastructure projects in general is that they lack visibility. If you're the mayor of a city and you allocate big bucks to fix the sewers and, in so doing, take money away from the school lunch program, the day care centers, or the new sports arena, you can take comfort in the fact that you did the right thing -- in all the spare time you'll have after you lose the next election. It works the same way for data processing infrastructure projects in a company -- except that those projects have even less visibility than public works projects in a city. If you're the mayor fixing potholes in the street, a citizen might come by and think, "Hmm, I think there used to be a pothole here. The mayor must have fixed it. He's doing a good job.", but with infrastructure projects like Y2K there are absolutely no visible results. Let's say it's 1990, you're the IS director of a company, and you want to start a Y2K project. After spending a few hours trying to get your boss to understand what you're talking about, he might say, "Let me see if I understand this. You want to spend massive amounts of money and take resources away from all of our other important projects so that ten years from now -- when, incidently, you and I will both be gone -- something that might have happened on January 1, 2000 might not happen."