Auld Lang Syne
by Gerald M. Weinberg
Should old acquaintance be forgot,
and never brought to mind ?
Should old acquaintance be forgot,
and old lang syne?
and never brought to mind ?
Should old acquaintance be forgot,
and old lang syne?
The Good Old Days
Ain't it great being an old-timer? I've been around the computer business for so long I don't have to compute any more–I can make my living telling stories. Telling stories is a lot more fun than computing. I know, because in 1952, I actually was a computer. That was my job title: "computer.". I was paid 90 cents an hour for inverting 10 by 10 matrices with pencil and paper–and lots of erasers. I used a huge mechanical Friden (they were the big name in computation back then) which I thought was the last word in computational equipment. It had all the processing ability of a four-function calculator (no memory) in a box about the size and weight of a dozen of today's laptops It could do a single multiplication in under 15 seconds, while making about the same sounds as a Cuisinart.
Back in 1952, the cost of a computer (me) was 90 cents an hour plus a few hundred for the Friden. The minimum wage was about 50 cents, so computing was rather expensive. You didn't hire a computer without giving it a lot of thought. Four years later, in 1956, I was working for IBM, programming a computer. I was being paid $450 a month–about $2.50 an hour. I worked with two different computers (by then, computers were machines). The IBM 650 rented for $80 an hour–32 times my wage. The IBM 704–at that time the biggest commercial computer in the world–rented for $685 an hour–274 times my wage!
By my current definition, the 650 and the 704 were personal computers, because my relationship to the 650 was almost precisely that of most of today's PC owners. I worked on-line, one on one with the machine. I had control of all the machine's resources, but I had to know hundreds of mysterious details to use them effectively. And most of the time, I had the machine all to myself––because nobody else knew how to use it.
On the 704, the situation was similar–except you were never alone with the 704. 704s were in short supply. To use the closest one, we had to fly from California to New York and share Machine #1 with everyone else. Not only didn't we have remote computing, we didn't have jet airplanes. So any time we used the 704, we had to add about two days of travel to the cost. Even so, the travel was cheap compared with an hour or two of machine time.
Of course, nobody got "an hour or two of machine time" just like that. Time on the machine had to be scheduled weeks in advance, and was parcelled out in precious 15-minute nuggets. When you worked with the 704, you really knew your place in the universe was minuscule. You moved fast, and you didn't make any mistakes. Mistakes would waste the 704's valuable time.
The 704 scheduling rules had one exception: the FORTRAN development team. This elite team could get seemingly endless hours of time while the rest of us could only watch helplessly from behind the glass walls of the computer room. It was bad enough being unable to do my work, but for some cockamanie idea about "automatic programming," it was intolerable. Those of us who had to wait behind the glass knew that FORTRAN would never fly. There was simply no way a computer could generate code as efficient as the code we expert programmers could write.
Buy or Build?
We were right. FORTRAN never did achieve the ability to generate code to equal the efficiency of a master programmer. In a few years, however, nobody cared. Machine time kept getting cheaper, while people time grew more expensive. In 1984, I can own a computer with much more power than the 704 for less than what I earn for one hour of consulting. And, if this cheap laptop didn't work, I could throw it away and have a new one delivered. Off the shelf, too, not after waiting a year to have a new one built by hand.
I still don't use FORTRAN. Why not? Because it's inefficient with machine time? No, because it's inefficient with my time. If I must write a program, I prefer APL, which may allow me to produce the same program in one-fifth the time. But if I can possibly manage it, I'll buy a program rather than write one myself. I can't always manage that, however. Even though I now consider my time to be very valuable, the economics don't always in favor a purchase. For instance, I recently needed a system to make cash flow projections. A lot of terrific spreadsheet programs can do that job, so choosing one ought to have been better than writing one of my own. But it wasn't. Let me sketch my decision process.
First of all, I had to decide what I wanted. A general purpose program like a spreadsheet represents a much bigger investment than the purchase price, so I wouldn't want to make such a decision without meticulous consideration of all my future needs. On the other hand, if I am simply going to write one special purpose program for myself, I don't have to be so careful. I figured I could develop such a program in under 2 hours, so if I didn't like it, I could modify it or scrap it with no big loss.
Once I knew the features I wanted in a spreadsheet program, I'd have to select one. If I wanted to do that intelligently, I'd have to survey the field to narrow down a hundred candidates to a short list of five or six. Then I'd have to gather the information on each of these, hopefully getting a demonstration and reading a couple of unbiased reviews. By the time I was finished, I could easily have spent three days on the selection process.
If I lived in a less remote place, I might be able to accomplish all this in a full day by visiting a computer store, but we don't have one of those in Tererro, New Mexico. As it is, once I decided which app I wanted, I would still have to wait a few days then drive to Albuquerque to pick up the mail. (We don't have mail delivery in Tererro, nor do we have internet access.) Then I would be stuck installing it on my own, which from past experience would require at least half a day, plus a couple of frustrating long distance phone calls.
Once I had the spreadsheet installed, I would turn to the job of converting my existing files to fit the requirements of the app. I could perhaps write a program to do this, but because the file formats of apps usually aren't well documented, I'd have to estimate at least a couple of days to get it working, if I were lucky. When writing my own program, of course, I simply use the file formats I already have.
Next I'd have to learn to use the spreadsheet. I would have to estimate about 4 hours to learn to do the first simple task–it takes at least 4 hours to learn to use any app, if you don't have a tutor at your side. The second task would probably be much easier, and I would start to regain my investment in the software.
How big is that investment? Writing my own program–deciding what I want, writing the code, and testing–might take 3 hours. Buying a package–deciding what I want, selecting the best package, installing, file conversion, and learning to use–might take more than 50 hours. In addition, the off-the-shelf program could cost me as much as $500, but if my time is worth more than minimum wage, the cash will be the smaller part of my investment.
The Real World
Of course, nobody actually buys software this way. Most of the time, I call up a friend who says that ClunkyCalc is the greatest spread since butter. I run down to the closest computer store and buy one–no time deciding what I want, no time selecting the package, and a friend to help me install it and teach me to use it while we share a bottle of our favorite beverage.
This way is not only cheaper, it's more fun. But there's still the question of converting those files. We begin to see why the software industry is moving away from isolated packages to integrated suites. Once you get hooked into one vendor's file formats, your decision on the next package is terribly skewed in favor of that vendor. For instance, after two years of using a new word processor, I had a large-folder filled with text–six or eight book manuscripts, a hundred articles, and several hundred miscellaneous pieces of text, including financial reports.
When I became dissatisfied with that word processor, it was almost impossible for me to consider a substitute that couldn't handle the old file formats.
In today's world, the choice of hardware or software is determined by tradeoffs involving a variety of issues, such as,
• How much are you paid for your time, or how much do you value it?
• How much do you have invested in your current system, and how much would it cost you to convert out of it?
• How much cash or credit do you have?
• What skills do you already have, such as programming, typing, or using a particular package?
• Who do you know, and how much can you count on them?
The Time Dimension
If you examine these questions, you'll see that each of them has an implicit time dimension. The older you are, the more likely you are to be paid higher wages, have lots of data stored in file cabinets or on magnetic media, have money in the bank, know a variety of skills on older systems, and maintain a network of people who can be called upon for advice.
Being an old-timer has a lot of advantages, but there's another side to the coin. Your higher wages may mean you can't afford to play with new ideas. Your vast store of data may lock you in to old systems which are less efficient than what you could buy today. Your money in the bank may convince you that it's better to buy solutions than work them out yourself, so you lose the opportunity to learn new things. Your old skills are another barrier to new learning, and your old friends may not, in fact, be reliable guides to today's technology.
When you've been in computing for half a century, you have wrestled with these tendencies for a long time. FORTRAN was only the first of many innovative ideas I scorned. Most of the new ideas did turn out to be useless, as I predicted, but there were a few that made me eat crow. If I hadn't been ready to humble myself–to drop some of my old success–and start back at square one with the beginners–I would have washed out of the computer business a half-century ago. I know because many of my colleagues did.
But in this business, you don't have to be around as long as I have to start suffering from technological senility. The system you bought two years ago is totally obsolete, but you're locked in by your huge investment in files and old skills. In fact, the clumsier the system is, the more you had to invest to make it workable–so the more you're locked in. If you want to try something new, your old buddies are threatened, and if you want to keep their friendship, you'll slip back into the good old ways, scoffing at the young whippersnappers who "don't really appreciate the good old days of computing, when we pioneers all had arrows in our backs."
How do you beat this tendency to become an old fogey before your time? I believe you must plan to invest at least 10% of your time and money investigating new things, and 20% would be better. You have to be ready and willing to take a total loss on your investigations. If you never read a stupid article, never go to a useless conference, and never buy a crippled piece of software, you're playing it too safe. You have to be willing to risk making a fool of yourself, otherwise you're sure to make a fool of yourself.
THE END