ACM Fellow Profile
Bob Glass
Bob Glass photo

A Conversation With Bob Glass: "a wonderful train ride"

Q: In thinking about your life's work, what springs to mind as the most defining moment?

Bob: Well I got my Masters degree in 1950's in mathematics and perhaps the most important, defining moment was that the job opportunities for a mathematician were pretty uninteresting. You taught or you worked for a code breaking agency. Neither one of those appealed to me very much. Fortunately just about that moment computing came along. Software jobs came along, and I went into industry and took a job with an American aerospace company and worked in a computing group. Off went the train and I went for a ride: a wonderful ride.

So you were one of the earliest people to go into the computing industry as it was?

Yes, there are not a whole lot of people in the field who go back as far as me. Frank Land in England has a history as a software professional that pre-dates me by about three years. Probably no one precedes him and several of his colleagues who worked for a very famous tea company in England.

Were there other seminal moments as you went along that helped form your interest in the areas that you ended up pursuing?

A couple of things come to mind. When I took my first job at North American Aviation I was the youngest person in that group. Three years later I left there and went to a company called Aerojet-General. In that organisation I was the oldest person. So suddenly I had gone from being the new kid on the block to a senior member of the field in a three year period. That was astonishing. But it shows how rapidly the field was growing back then. Aerojet had a bunch of new hires: two or three dozen people, all of whom were younger than me. So that was one of the most striking things about that time.

It does say something quite interesting though about the industry at that stage doesn't it?

It was a fascinating time to be a part of any field, and to be a part of the computing field at the time when aerospace was also emerging. I was in the computing field of aerospace so I was a part of the very pioneering efforts, and oh my goodness what a thrill. I don't think computing could have grown as rapidly as it did just on business applications which were the other major thrust of the day. I think it took aerospace to really drive the field forward.

So what sort of things did you do in aerospace?

Well the first job I had at North American was part of a group called Master Dimensions. Remember I was a math major, so this married my mathematical background and my new interest in computing. The job of Master Dimensions people was to make three dimensional representations of the entire aircraft, of all the aircraft in the construction inventory of the company. We measured things to a ten thousandth of an inch! The intent was that these dimensions that we created were fed to the engineers and duly fed to people on the assembly line. They would then build the aircraft to that kind of tolerance: ten thousandths of an inch. Think of an airplane flying rapidly through the air. You don't want the whole thing sticking out an inch or so beyond what it should! But the funny thing to us was that as we walked in past the assembly line to get to our little engineering offices, we would see guys on the assembly line putting aircraft together by hammering pieces into place. And we knew they were fitting to a ten thousandth of an inch: but nevertheless they were hammering them into place!

So tell us about the evolution and interaction of the two main streams (business and scientific engineering) of computing at this early stage?

Well the two married at some point. I worked at two companies where that marriage was consummated. It was always an uncomfortable marriage. Business people had one cultural background: conservative management-driven control; and the scientific engineering people came from another background: cowboy culture, freelancers, management-be-damned kind of thing. And when you put those two together in one organisation sometimes fireworks erupted.

So one was more individualistic and the other was more conformist?

Yes exactly. In fact the business people worked in the same building as we scientist engineers at Boeing (this was my third job). The business people were required every night when they went home to clean off their desks so that they were entirely bare. They would shuffle everything into a drawer at going home time, and the next morning they would pull it all back out gain. We all thought that was hilarious. Our desks were terribly messy.

What do you think got you involved in writing, and what influenced what and how you wrote?

Why did I write? It's a very unusual thing for a person in industry to do; it's not a goal that most industry people have. I grew up in an academic family: my father was a college professor and my mother was a college graduate, which was extremely unusual back in those days. I guess I inherited some of my tendencies towards things that lead to my writing.

My work influenced how and what I wrote about. When I was working at Boeing, it was a very successful company which excelled at manufacturing. Engineering was good, but manufacturing was how they made the money. As a result, the leaders of the company were often manufacturing people, not engineering people. That in turn led to a culture that de-emphasised the importance of the individual, and emphasised the importance of the team. That frustrated me because I've always seen my chief contribution to be as an individual, not a group one, not a communal one. Hence some of what I wrote I did so under an assumed name. I told failure stories many of which were from the Boeing environment. I disguised the name of the company, my identity and the key players in the stories. I published in Computerworld under the name of Miles Benson for five or ten years.

My writing then was very informal, more journalistic than academic. The reason for that was when I went through college I wasn't at all sure what I wanted my major to be. I drifted into mathematics because I seemed to be good at it. In retrospect I don't think that was the right choice for me, but that's what I did. However, I also took the college offers in journalism, and worked my way up to be editor of the student newspaper. Hence, journalism was always a passion of mine, and this writing was part of my need for a journalistic outlet I guess. I also did some reporting for Computerworld as a 'stringer', which in the journalistic world means you are not a salaried staffer, rather you are paid by the article. I was Robert L Glass writing articles and I was Miles Benson telling failure stories.

What do you think made you write stories about industry failure?

Why did I tell failure stories instead of success stories? Well there is the interesting thing about failure versus success. Failure tends to be permanent, success tends to be transient. Actually in one of my books I told a success story. I introduced it by saying 'people tell me that I shouldn't just devote myself to failures, I ought to tell success stories, so here's a success story'. It was the story of the wonderfully successful Intel 286 chip, which I got from an Intel corporate publication. Well, every other story in that book is still current and has application today. However, who cares about the 286 and its success? That story is totally outdated. There's something permanent about failure stories, and I stumbled into that area, without a conscious intent. I know that book is floating around out there with that ridiculous success story in it. I was never going to make that mistake again.

What do you think about your experiences in management?

The great American dream, or perhaps the great human dream is to work your way up the management ladder. You start out as a peon and you eventually end up president of the world or something like that. I took the first step up that ladder in my second job, when I was at Aerojet, where I was the oldest person in the group. I'm not management material and I hated it. I actually stepped in for a manager who went away on vacation. He had a bunch of rules by which he ran this organisation, and I disagreed with all of those rules. So then the question I had to deal with was: do I enforce those rules while he is gone?; or do I not enforce them because I don't believe in them? I didn't enforce the rules and that got me in a lot of hot water later on. However, I realised that until you get to be president of the world, you're always a middle manager: there is always someone above you who is giving you direction. The beautiful part of being at the bottom of the management ladder is (to quote someone else) 'you can't fall off the floor'! I actually put together a book called “Power of Peonage” in which I told stories about people who had taken advantage of the fact that they were at the bottom of a management hierarchy, and as long as they were doing their job well, they couldn't be fired. So it didn't matter how much you offended people, they weren't going to lop you off.

Did that early management suggest to you "I don't want to do this - this isn't me"?

Yes, I never have. That was it.

Did that help you pursue other directions?

Yes, and it was a very unusual choice. I imagine that there are very few people in the world who have chosen to remain being a technical person. The beauty of that in a software field is that my knowledge remains current today. Here we are in 2005, and I originally learned about it in 1954. For complex reasons, a lot of that knowledge is still valid. Going into management meant you very quickly left behind the technology, and so you would find it increasingly difficult over the years to manage people who did things that you didn't know about. I'm not at all sad that I made that choice, although it did cost me something. In most companies the management ladder is lucrative: there are fringe benefits in management which you don't get as a technical person. As a manager, you get to choose and steer the direction, which you typically don't get to do as a technologist. That made me sad, because there are some things I wanted to steer and I couldn't.

How do you think that industry should address the problem associated with managers who have lost their technical currency and are in charge of projects that have technologies that they don't understand?

There are so many fundamental flaws in the industry that I'm very happy that it's not my job to fix them! My role has never been to try to figure out how to fix such things, especially that one. You could obviously say some things about managers dipping their technical toes in the water again for a little while, then going back to managing again. But such proposals are all kind of naïve when you come right down to it, because that just isn't going to happen. So I don't know. My biggest concern, by the way, is not the gap between management and technical employees: my biggest concern is between academe and the whole practitioner field.

Do you think the academic-practitioner gap is exemplified by the fact that there are not many people in the computing field who are well known or well regarded by both academics and practitioners?

Fred Brooks is one. He worked on the IBM 360 operating system project. That was the origin of his book The Mythical Man Month. It is a marvellous book: the most important book in the history of computing software as far as I am concerned. While Brooks is an academic now, he came from a practitioner background. Brooks went on to be a college professor at North Carolina, and has been there ever since.

However practitioners would not know of Gordon Davis and he's probably the most senior and famous person in the IS world! There's a very good reason for that. Academics don't write for practitioners and therefore practitioners can't read what they write. So there's no way to bridge that gap as long as academics are only writing for themselves. And therefore the famous academics are not going to become famous for us [practitioners]. On the other hand, practitioners have to write in an accessible manner. To the extent that they write at all; they write material that anybody can read. Academics like to refer to that as dumbing down. I think that's a terrible phrase because it implies that somehow there is something better about the stuffy way that academics write, as opposed to the intelligible way that practitioners write. How's that for bias showing?

Can you comment further on your having stayed in the technical side of the profession?

My biggest fear in the field, and the strangest confession I can make is that at the age of 73 in 2005 I should not be up to date in the technical field of software. I last wrote a program over twenty years ago in about 1983! So how dare I say that I understand the technology? In fact there's a lot about the current day technology that I'm really not abreast of. However, that tends to be current day tools, current day operating systems; but it does not tend to be about how you build software. How you build software is pretty much the same as it was 50 years ago!

Do you mean methodologically?

I mean the actual act of studying requirements, building code, yes. I was reluctant to use the word methodology because that's become such a formalised thing these days.

Is process a little better?

No, same problem.

The approach or the way that you build software...?

At heart, it's not changed in 50 years. It's an interesting question whether or not it should have changed. I'm very grateful that it hasn't because I would be an old fuddy duddy out on a limb somewhere trying to pretend that I was a software engineering specialist at a time when I was totally out of date. It's still kind of striking because people love to say that software and computer hardware are the fastest changing fields in the world. In some senses they are, but in another very real sense software is not. And in fact while we have made dramatic changes in our ability to build computer hardware cheaper, smaller, more effective, and more efficient, the software interface of hardware remains pretty much the same. We still have fixed length words and binary. I sometimes think that when people talk about the rapid change in software it's really a case of software envy, where we wish we were like those hardware folks!

Can you tell us about your journal associations?

By the mid 1980's I'd switched out of industry and I was teaching software engineering at a graduate program at Seattle University. I was approached to see if I would be interested in being editor of the publication Journal of Systems and Software. They flew me back to New York City. It was the only time I ever met with anybody from Elsevier, and they hired me. So while I continued as a professor at Seattle University, I also had the one fourth time paid position editing the journal. It was very much an academic journal, even though academics thought of it as a practitioner journal. Almost all of its content was written by academics, and it still is. I've retired from that now.

About 1990 I realised that I wanted to do my own publication. So I started putting out a newsletter called the Software Practitioner, as I felt that it was an audience that was underserved. I call it the newsletter by and for people who build software for a living. I've been doing that ever since, and have not retired from that particular position. I also tried a newsletter called PERC (Practical Emerging Research Concepts) for a while, which focussed on bringing research results to the attention of practitioners, and written in practitioner language. It never really gathered much momentum and I finally gave up on it. I relied a lot on material from Lynn Marcus. She's an academic who is a magnificent contributor to the practitioner world. I would paraphrase and re-write Lynn's material into language that I thought the practitioner audience would appreciate.

I write a column for the Communications of the ACM called The Practical Programmer. I also do one for IEEE Software called The Loyal Opposition, which is an opinion piece that supports the notion of building software in better ways, but takes issue with how we are doing it now.

You mentioned that you were a Professor at Seattle, so you did end up going into academia?

I went into academia at Seattle around 1982 or 3. I considered becoming a professor every time I changed jobs in the aerospace industry. Aerospace is a funny place to work, as it is based on contracts which result in a boom and bust situation. They hire a bunch of people to fill the contractual requirements, and lay them off when the product is completed. I worked in the only industry where every house I ever bought, I sold for less than I paid for it. This was because I'd buy a house in the boom times when the community was growing, and sell it in slack times when everybody was leaving the company. I did that work for three aerospace companies, and each time I changed jobs I took a shot at teaching. My father had been a college teacher and eventually I connected and that's when I went to Seattle University.

And did you enjoy that?

I enjoyed it a whole lot, I failed to get tenure. Incidentally I talked to a lot of people over the years who failed to get tenure: names that would be quite recognisable if I were free to share them. While failing to get tenure is not that unusual, Seattle University wouldn't tell me why. Being a private institution there were no laws governing what they had to tell people, but I figure it was because I didn't have that PhD. They were bound by the rules of the accrediting bodies that they had to have a certain percentage of PhD's on their faculty and I wasn't one of them. It didn't matter that my teaching ratings and publication record were better than a whole lot of other fulltime faculty. I'm slightly bitter about that because I had to leave some place that I really didn't want to leave.

Let me tell you my second dramatic failure story. It was actually my final programming job and I was working at Boeing in the early 1980s. I was struggling to find somewhere that would take someone like me on as a programmer, since I was senior in the field and making a lot of money as a technical person. You know, when you get to be senior in the field they expect you to do senior tasks. I was in a research and development group dealing with a range of tasks, half of which were senior non-programming tasks. I wanted to be a programmer. I was grudgingly allowed into a group that was doing micro computer software development on a word processing package. So many interesting stories I could tell about that but we don't have time for those. However, the time came when they had to cut staff, and I was one of the first people to go because I was paid probably twice as much as some of the other younger people. I was really angry at that point in time and yet I fully understood why they did it. It was just not what I wanted to happen. It's what I wanted to do, and it was the closing of the door. If I couldn't work for that organisation doing somewhat innovative things building software, then who was I going to work for? Not long after that I went back to an R & D group. Soon after that I went to Seattle University because I realised that the door at the end of my technical career as a programmer was closed. Despite my wish to stay in that profession, nobody was going to hire me to do that anymore. They won't give you a cut in pay because they figure you'll leave as soon as someone offers you more money. So the door was closed in a very final way.

Has your family and work life been closely connected?

Well I think that the most important thing to say about that is that my intent was to always put my family first. For example, one time when I was working on a proposal for Boeing I had reservations at a resort in the San Juan Islands. On the Friday afternoon I was told that I couldn't leave because I had to get some material together the next day. However, I delegated that task to someone else, and went on vacation. I suffered a lot over that, even though I still believe I did the right thing by putting family first. We as a family had made that plan, and I thought Boeing had no right to ask me to defer it when I had ensured that their needs were covered. As far as I was concerned that was the issue. I didn't leave them in the lurch, and the guy I left in charge did a good job. When the time came to change jobs, that was a family decision, but it almost always coincided with what it was I was trying to do.

Have your wife Iris's academic career interests influenced your work?

She opened my eyes to a lot of different people and ideas where I was working in academe, across the whole field of information systems. Furthermore she had written some of the primary, underlying literature that's important to both information systems and computer science. She alerted me to people like Herbert Simon who wrote The Sciences of the Artificial. I have come to believe that it is actually one of the top five books in importance in the field of computing. She opened my eyes to Keen's articles, scientific revolutions or something like that, and it's an excellent book. I found the title of the Sciences of the Artificial to be really profound, because Simon is defining something particular about software: that it is artificial, which is not true of any other science. When we work in the software field we are dealing with artificiality, something created by human beings. Software is this thing that has no weight, no volume, no presence: you can't reach out and touch it. And yet it has this profound impact on our lives: it's artificial and the title alone captures that beautifully. That software is something artificial explains why it has a difficult time borrowing ideas from other fields of traditional engineering. There's a lot that you can't borrow from traditional science.

Because traditional science is not artificial?

That's right.

Bob Glass was interviewed by Fiona Darroch, Department of Information Systems, University of Southern Queensland, Australia.  Mark Toleman, also of the Department of Information Systems at the University of Southern Queensland, assisted with review and editing.