Oral-History:Jon Squire

About Jon Squire

Jon Squire was an influential software engineer and manager at Westinghouse from 1963 until 1996. At Westinghouse, he was the lead engineer on compiler developments for Fortran, Neliac, Jovial, and Ada compilers for embedded computers. Squire also helped develop digital and analog circuit simulators with associated queuing and scheduling models that became the basis for the Westinghouse Computer Aided System, CAS. While at Westinghouse, Squire taught courses on computer aided design, Fortran, and Ada. He retired from Northrop Grumman in 1998.

In this interview, Squire talks about his experience at Westinghouse and reflects upon the different radar and computer projects he took part in. Squire also talks about his experience with teaching both inside and outside of Westinghouse. Squire is currently an Adjunct Faculty member at the University of Maryland Baltimore County and a Lifetime member of IEEE.

About the Interview

JON SQUIRE: An Interview Conducted by Frederik Nebeker, IEEE History Center, 14 October 2010

Interview # 556 for the IEEE History Center, The Institute of Electrical and Electronics Engineers, Inc.

Copyright Statement

This manuscript is being made available for research purposes only. All literary rights in the manuscript, including the right to publish, are reserved to the National Electronics Museum and to the IEEE History Center. No part of the manuscript may be quoted for publication without the written permission of the National Electronics Museum and the Director of IEEE History Center.

Request for permission to quote for publication should be addressed to The National Electronics Museum, P.O. Box 1693, MS 4015, Baltimore, MD 21203 and to the IEEE History Center Oral History Program, 39 Union Street, New Brunswick, NJ 08901-8538 USA. It should include identification of the specific passages to be quoted, anticipated use of the passages, and identification of the user.

It is recommended that this oral history be cited as follows:

Jon Squire, an oral history conducted in 2010 by Frederik Nebeker, IEEE History Center, New Brunswick, NJ, USA.

Interview

INTERVIEW: Jon Squire
INTERVIEWER: Frederik Nebeker
DATE: 14 October 2010
PLACE: The National Electronics Museum, Baltimore, MD.

Background and Education

Nebeker:

This is the 14th of October, 2010. I'm at the National Electronics Museum talking with Jon S. Squire. This is Frederik Nebeker. Could we begin with where and when you were born and a little about the family you were born into?

Squire:

Born in Detroit, Michigan. January 9th, 1938. Pretty normal family.

Nebeker:

What did your father do?

Squire:

He was the credit manager for Associates Discount Corporation in Detroit.

Nebeker:

What is that?

Squire:

They financed probably two-thirds of the cars and trucks, at that time you had special companies that did financing. It wasn't so much the banks.

Nebeker:

I see. Or the automobile manufacturer.

Squire:

Right.

Nebeker:

Did you grow up in Detroit?

Squire:

Yes. Went to Edison Grade School, had about 800 students there then went to the high school there had about 3,000 students in high school. Went to the University of Michigan, had 24,000 students —

Nebeker:

[Interposing] [Laughing].

Squire:

— and of course went to Westinghouse at 124,000 students, err —

Nebeker:

[Interposing] [Laughing].

Squire:

— employees [Laughing]. Yes, they were students. [Laughing].

Nebeker:

Were you interested in science as a kid?

Squire:

Yes. I had built my own electronics lab by the time I was about 8 years old.

Nebeker:

Is that right? So crystal radio?

Squire:

At that time we had Heathkits. So the first thing you built was a volt and then you built an oscilloscope and then you scavenged parts out of radios and that's how you got your resisters and capacitors and so meter

Nebeker:

[Interposing] Oh so you were really into it even then

Squire:

[Interposing] Oh yes. So by the time I was 12 I knew I'd be an electrical engineer.

Nebeker:

I see. Tell me about your college years. So you went to the University of Michigan at Ann Arbor? Lot of fun. A lot of work.

Nebeker:

[Interposing] In these days did they have a separate electronics track?

Squire:

[Interposing] Well it was an Electrical Engineering Department. No we had to work with both DC machinery and with circuits.

Nebeker:

So you got a lot of the power engineering as well —

Squire:

Yes. It was all combined at that time. I joined the IEEE student group, it was actually IRE back then. And I was student chairman of the IRE group there. Got my Bachelor's degree, got my Master's degree in EE, got a Master's degree in Math.

Nebeker:

Now this is right after the war?

Squire:

I went to college, I got out of there in '63 with two Master's degrees

Nebeker:

So we're in the late 50's that you're going to school.

Squire:

I didn't go to Korea because I was in college.

Nebeker:

And things must have gone well because I see you've continued for two Master's.

Squire:

Right.

Nebeker:

What did you go into more specifically?

Squire:

Oh the second one was in math.

Nebeker:

[Interposing] Right. But your first Master's, that was electronics?

Squire:

Yeah, EE, right.

Nebeker:

So you were you thinking of becoming a computer engineer?

Squire:

No I was working toward a PhD. I just didn't make it. I got too good an offer from Westinghouse. So I had enough credits so I took the Master's degree in Math.

Nebeker:

Oh so you went —

Squire:

[Interposing]

Nebeker:

I see. So your original intention was to be in academia?

Squire:

No.

Nebeker:

A PhD and then go into industry?

Squire:

[Interposing] Yes.

Nebeker:

Oh I see. And the master's in mathematics was just because you had taken courses along the way?

Squire:

When you were an EE back then you had to have a lot of math and it turned out I had enough math courses to qualify for a Master's degree in math.

Nebeker:

I see. And at that point were you interested in computers?

Squire:

Oh yes. We had had one of the real old computers. I had actually programmed an LGP 30 which is a magneto-strictive delay line computer.

Nebeker:

Hum.

Squire:

And then we got an IBM 650. It had a magnetic drum. And by the time I was out of there they had an IBM 704, a real computer. So I was doing a lot of software as well as electrical engineering.

Nebeker:

I see.

Squire:

I was a ham radio operator. I was K8LOO.

Nebeker:

When did you start as a ham?

Squire:

While I was in college. Somebody there offered the code class and I got my technician class license.

Nebeker:

Those days you had to know code [chuckling].

Squire:

Yes. And as a graduate student I worked at the University of Michigan Research Institute. I helped a guy develop the first parametric amplifier. I was just the lab tech.

Nebeker:

So this was a part-time job while you were studying?

Squire:

Right.

Nebeker:

Well that sounds interesting. Was it your intention, did you take to computers so much that you could see that was the direction you were going to go?

Squire:

Yes.

Working on Radar and Computers for Westinghouse

Nebeker:

So what was this job offer that came?

Squire:

Well I interviewed AT&T, Bell Labs. I interviewed with Boroughs Corporation and then one of the people there had come to Baltimore to Westinghouse and so I interviewed here. And I had to come to work here.

Nebeker:

[Laughing] Explain that please.

Squire:

My interview was scheduled with George Shapiro for 9:00 o'clock and I got here a little early and I was sitting there. And I waited a half an hour for him to come in. And he explained, oh, traffic is too heavy. So I don't get in until 9:30. I knew that’s the place I want to work. And for my whole career, I seldom was in before 9:30 but I was often working at 6:00, 6:30, 7:00 o'clock, you know. So that's the type of group it was.

Nebeker:

I see. What was that group?

Squire:

George was responsible for digital computers to go with our radar and software for them.

Nebeker:

[Interposing] This was in the radar?

Squire:

We were in the East Building, Aerospace Division.

Squire:

So our main product was airborne radars. When I got there we had just done our first one which we called the AUG10 digital, Westinghouse had built the AUG10 analog radar. We went on from there to build a mili-computer which was a militarized minicomputer. My group did the software for it, like the assemblers and linkers. George had Jim Hudson working for him who did the hardware and the computers. And then my people did the embedded computer programming. We did the software, the real-time software. And so throughout the years we did a computer for NASA, OBP, the On Board Processor, did militarized computer ANAYK15. So my group did the support software and then the mission software for that.

Nebeker:

Well one of the first radars you worked on, you said that was a digital?

Squire:

Digital, we had just converted the analog radar to a digital radar. That was for the F4. —

Nebeker:

[Interposing] Is that —

Squire:

— yeah that was for the —

Nebeker:

Was it characteristic of that time that radar systems were going digital?

Squire:

Well everything was analog before that because this was in '63, '64 and so the digital world in avionics was just starting

Nebeker:

I know Bell Labs was starting to go digital with their long distance lines about the same time.

Squire:

Right. We were competing with RCA and a few other companies to see who could get there first. Since we had the radar business, we were able to get our computers into the radars. There was another group under Kaplan that did the signal processors.

Nebeker:

How would you explain for the layman why it's an advance to go from these analog radars to digital radars?

Squire:

Accuracy. You could get, if you really worked 3-digit accuracy out of an analog computer, you could of course get 6-digit accuracy out of a digital computer. So as we were trying to get more range, tracking better, we really had to go digital.

Nebeker:

So with the same antennas and so on you could just get more accuracy.

Squire:

Well, everything was improving. Power was improving for the radar so that you could get greater range. We were able to manufacture better antennas. I actually had software people working for me who programmed the machine tools in the factory to machine the antennas. Bob King was one of those people. And he eventually went to the turbine division so he helped them out to get better turbines.

Nebeker:

What do they call that? The numerical control of machines?

Squire:

Yes.

Nebeker:

That's probably a fairly early example of that.

Squire:

Yes we wrote our own software, cut our own Mylar tapes.

Nebeker:

Uh-huh.

Squire:

I mean printed punch cards had just come out. [chuckling] Well actually I used punch cards at the school.

Nebeker:

So you jumped into some exciting work, it sounds like.

Squire:

Right.

Nebeker:

This is mid 60's.

Squire:

I had to build a group. My main job was to build a group of software engineers. Everybody we hired had to have a college degree, professional. And we had to develop the software group. And so George Shapiro was supportive. We had Johnny Pearson who was an engineering manager who was supportive. Earl King worked in the personnel department.

Nebeker:

You were heading this software group?

Squire:

I was manager of the software group under George. We started out with like three people and built up to a group of about 20.

Nebeker:

[Interposing] Over what time period?

Squire:

Five, seven years as work went on.

Nebeker:

I see. What was the division you were in?

Squire:

Aerospace Division.

Squire:

We tended to have one big project at a time. We did the WX 200, we did the F 15 fly off, the F 16.

Nebeker:

But typically consecutive things.

Squire:

Yes. EAR radar, HELRATS radar. So we had to support the software throughout all of it.

Nebeker:

And how did the programming go in those days? Did you first do a flow chart and then punch cards.

Squire:

Yes, I was kind of on the cutting edge, University of Michigan had a real good software program in addition to EE. They didn't have computer science then.

Nebeker:

Yes.

Squire:

So the government required we deliver them flow charts. I had one of my people write a program that would read the source code and draw the flow chart after the program. Programmers don't like to draw flow charts.

Nebeker:

[Laughing] I remember those templates.

Squire:

Yes, oh yes, we had the templates.

Nebeker:

But you just wrote the program and then generated the flow chart afterward [chuckling].

Squire:

Right. And what we found with the computers was that the engineers, the digital designers, needed a tool so my group also developed what we called a computer aided system. Our first one was just to simulate digital logic. Kelly Overman built one of our first computers. We simulated it and he was able to make sure his divide algorithm worked before he built it. So he was thrilled. We went on for years. We wrote the software that ran the wiring machines. For a while we used Gardner Denver wiring machines, as well as the machining of the antennas, printed circuit board layout. I had three types of software. One was what we called support software. These were assemblers, compilers used to program the embedded computer. Then we had the CAS software. Glen Hayes headed up the CAS software effort and that was simulation and layout. And then we had the embedded computer software. Now generally when my people worked on that, they actually went to the project area.

Nebeker:

I see.

Squire:

And the project ran the software.

Nebeker:

Tell me about those embedded computers at the time. They're built at Westinghouse?

Squire:

Oh yes. We built our own. And the reason was Intel was around and had small computers and IBM had computers but they were not airborne qualified. And they also didn't have the right interfaces. So we built our own digital computers and they were tailored to speed and size to go with a specific radar.

Nebeker:

Well I certainly understand the advantages of designing a computer for a particular application but what is it that's required for airborne computers?

Squire:

Mainly the real time, you have to be able to take your inputs, process them and get your controls out, and you've got to do it in real time. And therefore you don't want an operating system. John Stoopnagel worked with our group back then. And he developed what we called the cyclic executive so that we didn't need any interrupts. The program just cycled through. It would read the inputs do the computation, do the control so we could meet the real time requirements.

Nebeker:

I see. There must also have been demands of ruggedness and so on.

Squire:

All the hardware was mil spec, yes. That's why we couldn't use commercial computers.

Nebeker:

Yes. I see.

Squire:

Some of them got very powerful. Irv Kaplan [name?] built some signal processors that were state of the art for the time. FFT machine because the radar stuff had to do the FFT.

Nebeker:

I see. If we could digress a bit, how did that change over time? There must have been a point where you're going to application specific integrated circuits for some of this processing.

Squire:

The first circuitry was dual inline packs and you got four flip-flops in a pack. You got a 4-bit adder in a pack. So we had to work with that. And then as time went on we'd buy bigger and bigger integrated circuits. We still put them on printed wiring boards. We had 12-bit computers and 16-bit computers, then went to 24-bit computers like AWACS.

Nebeker:

Well the very first integrated circuits were in the 60's. Do you remember when that's coming into the radar work?

Squire:

But we bought those parts.

Nebeker:

Yes.

Squire:

Now we had ATL which built some specialized stuff for our radars. But they didn't build our digital circuits. So we mainly bought from like Motorola. Motorola had their ECL line out at that time and meta-couple logic. Then we got over that. We went to transistor, transistor, T-squared, L…

Nebeker:

What language were you programming in?

Squire:

Assembly language at that time. Now eventually we had the mili-computer. We did a Fortran compiler for it. FORTRAN was the big language back then. We did a job for the Navy and actually under contract, we did a NELIAC compiler for the Navy. And we sold that to the Canadian Navy. The Surface Division built the Westinghouse 2402 which was a shipboard computer. So we skipped over to the other division and helped them out.

Nebeker:

I see.

Squire:

And then eventually the Air Force went to JOVIAL. That became their programming language and so we wrote JOVIAL compilers and then eventually DOD 1. We got Ada compilers, so we wrote an Ada compiler. So all the software that was needed to program the embedded computer, basically my group had to do it. Now over time then we would buy it, in other words, we were on the leading edge but eventually we could go out and buy that stuff. So eventually we bought our JOVIAL compiler. We bought our Ada compiler that way we didn't have to continue to do support on it.

Nebeker:

I imagine you felt that you were on the cutting edge of this technological revolution there.

Squire:

We were.

Nebeker:

And that must have been one of the attractions of, of going to Westinghouse.

Squire:

I mainly got there 'cause I could sleep in late. [Laughter]

Nebeker:

So if we try to move chronologically here, you've mentioned a couple of the projects you worked on early on. If I could get you to name some of the big efforts that you were part of.

Squire:

It was always a whole bunch of small things. [Laughing].

Nebeker:

I see. So they're coming so fast that it's not like you're six years on this one.

Squire:

Yes. We were experts at what was called reuse of software before it became a buzzword in the industry. So each system was built on improving the previous one.

Nebeker:

[Interposing] Yes so you would take sections of this earlier program.

Squire:

Right.

Nebeker:

And were you still putting these programs on punch cards?

Squire:

We went to punch cards for a while and my group. I spotted a terminal, It was called an Execuport [spelling?] It would be called a laptop today but it was twice as heavy. We hooked that up over the phone lines to our computer and it worked. So we got more and more terminals in. Eventually we got VAX computers. We had big UNIVAC computers then we had VAX computers and so everybody in my group had their own terminal. So then we were online.

Nebeker:

Okay. So that's a big transition with computing, instead of punching the cards and submitting them you actually worked in real time at the terminal. When did that take place in your view?

Squire:

[Chuckling] I can't remember the date. We were still programming in assembly language very late, like the AWACS radar, 65,000 lines of assembly language. That was probably one of the biggest assembly language programs around and the reason for that was they got it written, they had it working, and they didn't want to rewrite it in a higher language.

Nebeker:

Yes.

Squire:

So I think the first higher language was the EAR radar. Gwen Hayes ran the software on that one. I'm very pleased because a lot of my people actually got higher ranking jobs that I had [Laughing]. Gwen Hayes made it to, I think a division manager. Something like that. She gave one of these talks. So Gwen Hayes, Doug Lengel, John Stoopnagel all of them burbled up and were higher level managers than I was. That's a good thing when a manager sees their people promoted.

Nebeker:

Did you resist moving up in management?

Squire:

I actually grumbled that I didn't want to become a manager because I was such a techie. But being a techie I used the computer and I automated my management job so I was doing technical work all the way to the end through B-level manager because I could. The stuff that would be routine for some managers, I had automated, [Laughing] and that left me time to do technical work. So I had a great time at Westinghouse.

Nebeker:

Tell me about the software in the 60's and then I suppose moving on there from that, the testing of it and the verifying of it and so on.

Squire:

We actually established an independent group that was software quality assurance.

Nebeker:

Within your group or is this outside?

Squire:

[Interposing] No, outside. And don't forget, mine was one of two major software groups and then there were a couple of other ones. Surface Division had their own and some projects had their own. So we wanted the software quality assurance to be independent of the groups.

Nebeker:

It's working with all of the different software groups.

Squire:

As each software module was finished, the software engineer who wrote it would present it to software quality and they would go over it and check it for whatever was appropriate. Did they test it, was it tested enough? So we had unit testing. We had integration testing. Everything you would see in a major software effort. And we kept up. When CMU came in with their software quality and their different levels we got to be a level three software certified group which we needed for government work. We kept up with the literature. We presented papers. We were pretty well right at the leading edge of technology all the years.

Nebeker:

I imagine that the programs are getting bigger and bigger as the radars get more and more complicated in what they do. There are many notorious examples of big software projects that have gotten into real trouble. Did you have any real problems?

Squire:

[Laughing] Every software project gets into trouble. We couldn't check out stuff out until all the hardware was there. So any delays in either the radar electronics or the computer electronics or interfaces or displays would hold us up. So we were always the last one to be finished before we could ship. And so yes, we always had pressure. We always had problems.

Nebeker:

But you, you managed to solve those problems?

Squire:

Yes.

Nebeker:

It was never a case of giving up on something?

Squire:

Oh no, no, I mean we had to. We had a contract with the government to ship radars. There was no option. You had to get it working. The first test would be down in the labs down in the basement and then we'd move it up to the roof. The radar would actually look out and we'd check it out and then it would go in the aircraft. And we'd fly it out of our own hanger, BWI, and then it would go out to whichever service was buying it and we'd test it at their field.

Nebeker:

Were there often surprises as you moved up in this hierarchy?

Squire:

Occasionally we would actually have to fly a software engineer so they could be up in the airplane seeing what was going wrong. Because the description of the error, our people couldn't comprehend it so the so we got a couple of people flight qualified [Laughing].

Nebeker:

I was thinking also that you know one might imagine, okay, it works, it works in the lab it should work in these different settings.

Squire:

Right. Our fire controls radars we actually would launch the missiles and stuff like that and we would occasionally have a timing problem because you're talking about the military's latest, greatest, high performance air craft. And we were given the specs but then you go up in the airplane and these guys are jockeys. [Laughing]. They can fly that plane around something terrible. So a couple of times we had to tune up the software. Make it faster. But generally the code was right. It was tested enough. That there weren't silly bugs in it because you had the whole sequence of unit test, integration test, bench test.

IEEE & ACM Memberships and Getting Published

Nebeker:

Okay. You remained an IEEE member I know and I see you were also a long time member of —

Squire:

[Interposing] ACM, the Association for Computing Machinery. And due to my math, the Society of Industrial Applied Mathematicians, So I'm still a member of all three of those.

Nebeker:

And what was it that kept you a member, their publications or the conferences or other activities?

Squire:

Generally while I was still at Westinghouse, the publications and then when I was thinking about retiring, I talked to some people at UMBC about teaching and I said oh I'd better keep them up [Laughing] so, publish or perish.

Nebeker:

[Interposing] Well in the case of IEE as soon as you make life member then you've made it, but [Laughing].

Squire:

ACM has got something similar.

Nebeker:

Now I see that you’ve done quite a few quite a few publications, Was that encouraged at all by Westinghouse?

Squire:

Yes —

Nebeker:

[Interposing] And a lot of this must have been classified.

Squire:

— but we had to clear them of course. And they had to be appropriate to the business. The classic story was one of my people was a sports enthusiast and had invented a new type of bow and wanted to patent it. And the company said no, that's not our product line. So they had to be publications and presented papers relative to the business area. Because the company funded your trip there and things like that.

Nebeker:

Right. Was there an issue with the classified work?

Squire:

— Well we knew not to put anything classified in there, the papers so —

Nebeker:

So you're talking about some programming technique or method and as long as it's general it's not an issue

Squire:

Right. Of course we'd never publish anything about a radar algorithm or anything like that. That was all classified.

Nebeker:

Yes. Were conferences important to you?

Squire:

I enjoyed them because I got a chance to go on a trip and present a paper and stuff like that.

Nebeker:

But also in terms of learning what people are doing elsewhere?

Squire:

Yes, we would get one or two of those a year. We'd have a budget for it. You had to live within your budget of course. And Doctor Pan liked me and I got a lot of IR & D money so I generally had IR & D projects running every year.

Nebeker:

Oh. Can you tell me about any of those that were interesting?

Squire:

That's what started our computer aided system, was IR & D money to be able to simulate first our computers and then more and more the radar. And he funded the compilers so we could be one of the first with JOVIAL compiler and one of the first with an Ada compiler.

Simulating Radar and Computers

Nebeker:

Tell me about that simulating. I can understand simulating the radar. You said you simulated the computers?

Squire:

Right. Because, don't forget, the computers at that time were made out of dual inline packs that you put on a printed circuit board so we would write a digital simulation model of each part. And then the design engineers would give us the string list of how they're wired together and so we could run a simulation. And then we could actually take and write a program and we could simulate what that program would be. So before the computer was built, we were starting to check out software. And at that time, that was kind of a new thing. Of course Intel does it all the time now. It became standard.

Nebeker:

[Interposing] And then you also simulated the whole radar system?

Squire:

Jim Mims [spelling?] in a different group mainly would lay that out. Sometimes my people would help and sometimes other people. But yes, our radar systems engineers ran detailed simulations of the radar before they released the specs to have them design the hardware.

Nebeker:

I think that's one of the big transitions in the second half of the 20th century, this from a kind of cut and try engineering, empirical work to you're doing the design work with computer simulations.

Squire:

Right. And as our computers got bigger and faster we could do more and more detailed simulations.

Working for Westinghouse in the 1960s & 1970s

Nebeker:

How was it going for Westinghouse Electronics in those years, the 60's and 70's?

Squire:

We were right up there, maybe sometimes the biggest. One of our top competitors at that time was Hughes. And then different competitors came and went while we stayed pretty big.

Nebeker:

There must have been some ups and downs when defense money was cut back.

Squire:

We didn't win the F 15 radar so we worked harder and won the F 16. We had a few layoffs along the way. So, yes there were some ups and downs.

Nebeker:

So how did it go for you? You started the software group and you said it grew from 3 to 20 people in that group, was that around the end of the 60's, '70 time?

Squire:

That was into the 70's I guess, yeah.

Nebeker:

How did it go from there?

Squire:

We stabilized about that size because they then spawned more software groups. The air traffic control people had their own software group. Surface Division had their software group and Hunt Valley had their own software group. So rather than any one software group getting huge it was distributed.

Nebeker:

Again a bit of a digression but I'm wondering about how software engineering became this recognized branch of engineering. I mean when you were in school probably that wasn't —

Squire:

Yes, you were called programmers. I don't know if I was the first one but at Westinghouse you were hired in as an assistant engineer, associate engineer, then it became engineer, senior engineer. We were doing software so I called my people software engineers, rather than programmers. Because they all had college degrees. And we really treated software as an engineering discipline.

Nebeker:

But also in those years the kind of more of a theoretical basis for that type of engineering is emerging in universities are starting to establish programs and stuff.

Squire:

Right, you had mills that would throw over the wall and keep design separate from programming and that never worked very well [chuckling]. And object oriented programming came along and I guess before that structured programming one entrance, one exit. We went through all that.

Nebeker:

[Chuckling] What was particularly valuable among the things that you've just mentioned, structured programming, object oriented?

Squire:

The thing I found was there was, and this was published in a book, there was no silver bullet in software. Every one of those they put out as a big deal and really it was a small increment in the growth of software. Even today object oriented programming only applies to about one-third of the type of software we do. And you've got whole languages that are based on object oriented programming. For the type of program it's good for, great, but when you write a compiler that's a different of programming. When you write real time software that's a different type of programming. So we kept up with all the trends but we never overdid it and got mired down in a new trend. We picked the best part of it and kept going from there.

Working with and Evaluating Ada

Nebeker:

And I know also with languages, as for one the Defense Department required Ada, and there were often thoughts that okay this language is going to really mean a lot have you seen — ?

Squire:

[Interposing] Right I actually worked it, it was called HOLWG, High Order Language Working Group. So I was actually part of the review team to review Ada and then I had my group do an Ada compiler. We had the first Ada compiler for the 1758 —

Nebeker:

Please tell me about, about that.

Squire:

Right. The idea was if we had a programming language where it did a lot of checking, we'd minimize errors. And so the Ada language was designed with strong typing. Basically everything that could be checked that was reasonable was checked. And it did help minimize errors. We dealt in defects per 1,000 lines of code. And we wanted to drive that to zero. And in commercial software it's floating around these days probably at about 1 defect per 1,000 lines of code. Microsoft has 2 million lines of code so you can guess how many defects they have [chuckling]. Okay. Well we had defects too. And you just had to work to get those out. It worked out pretty well. Our group did not resist it. Some companies resisted.

Nebeker:

[Interposing] Oh you were part of a group that evaluated Ada?

Squire:

Yes. We evaluated proposals, put in suggestions of what should go in the language worked with Gene Ishbia [spelling?] to get the first design of Ada. Eventually I was on the Ada numerical working group, part of the Ada repertoire group. So I've been active in Ada. I still am active in the Ada group. They're working on the 2012 release of the language.

Nebeker:

So you, you were probably a proponent of the use of Ada.

Squire:

Yes. One of my really bright employees Andy Griffith went up to a meeting. They were working on a new hardware design language and it became known as VHCL and he proposed it be based on Ada. And they went with his proposal. So we've got a hardware design language, VHCL that's based on Ada. And these were the outgrowth of — we started with Fortran and eventually had ALGOL. See NELIAC is the Naval Electronic Laboratory International ALGOL Compiler. JOVIAL is Jules Own Version of the International ALGOL Language [Laughing].

Nebeker:

So ALGOL was very much used for a while.

Squire:

Yes. And ALGOL was the ACM publication language for a while. And now of course we've got Python and Ruby and [Laughing] zillions of languages.

Nebeker:

When was it that Ada was being developed?

Squire:

Oh my. Ada '83 was the first standard and so it was soon after '83 was probably the first time we used it on an actual computer. So '84, '85.

Nebeker:

And when was it that the Defense Department required Ada in their contracts?

Squire:

It would be around '85, '86. And it wasn't required on all programs. The Air Force had caused the development of JOVIAL. JOVIAL was the Air Force's language. And so they slowly transitioned from that to Ada. The Army transitioned at a different time

Nebeker:

How did that go, the move to Ada?

Squire:

Our training program was not difficult. The toughest transition was to get some of our management off assembly language. They were thinking that higher language is going to be so inefficient, we're going to have to build bigger faster computers. But it my group pushed it. I pushed it. So going from assembly language to higher order language was a difficult step. But then from language to language — I call it syntactic sugar. The commas and semicolons went in different places but yeah, come on.

Nebeker:

I see. Oh that's very interesting because there must still be people who program in assembly or?

Squire:

The core of the operating system on every computer is still written in assembly language. Some hardware drivers like for sound cards and — things like that. But very little. We still at UMBC teach a little assembly language so that people understand why they're using compilers.

Nebeker:

And these people at Westinghouse who were reluctant to move to a higher level language they were won over after they —

Squire:

[Interposing] Yes. And from both pressure inside and then pressure from the government. Jean Sammet wrote a book called The Tower of Babel and it shows that the government was supporting over 100 different languages, many of them assembly languages. And the support costs were going up. That was part of the pressure to go to a few higher languages. They of course never achieved just Ada. You'd never get down to just one. Just like potato chips. You can't just have one.

Nebeker:

[Laughing] So from your perspective, here at Westinghouse, that was a good effort, Ada and it got used effectively and —

Squire:

[Interposing] And it helped us win some jobs because we were one of the first to have our own Ada compiler so we could say we could program in Ada. So eventually a company called ACT produced JOVIAL compilers and then Ada compilers. Since they were producing it for a number of companies their support costs were less. So it made sense to buy them. Today they outsource everything [Laughing].

Teaching at Westinghouse

Nebeker:

I think I saw that you were involved in teaching while you were at Westinghouse.

Squire:

Oh yes. We had the Westinghouse School of Applied Engineering Science. I taught how to use our computer aided system. I taught programming languages. Way back we had bought a timesharing service and we had the Basic programming language available. You programmed it by sitting at a machine and making a paper tape and running the paper tape in. So I taught a lot of our engineers how to program in Basic. This was probably around '64. [Laughing]. And then along the way I taught programming language, different design classes, all related to software.

Nebeker:

Tell me about the Westinghouse School of Applied Engineering Science.

Squire:

I'm not sure who started it but we held the classes in the evening at the plant. And they were taught by either systems engineers or expert engineers in some field or sometimes managers. It really helped because we were teaching our engineers the stuff they would actually be using. So it was different than a college course that was generic. It was very focused. And this really helped.

Nebeker:

And were all the instructors Westinghouse people?

Squire:

Almost all of them. Back as the Cold War was going on we had an instructor come in to teach Russian and I took one of the courses. [Laughing]. I didn't know at that time, [Laughing] so place your bets

Nebeker:

Why was that thought to be valuable for Westinghouse people?

Squire:

We tried to get as much intelligence we could on the Russian radars because we also built jammers. I never developed my skill enough to be able to read it but I could read a Russian math book by the time I was out of there because math is pretty standard across the world. But the idea was if we needed it we wanted to have people who could actually read the Russian text. I think our 3-letter friends really did most of the work in passing information on to us.

Westinghouse during the 1970s & 1980s

Nebeker:

I'd like to hear more about some of the other work you were doing in the 70's and 80's.

Squire:

Basically we worked in conjunction with Surface Division so that the computer aided design running the machine tools, the numerical control, could be used by both divisions, Surface Division built a 2402 computer and my group went up to Canada. We sold it to the Canadian Navy. That's why we had to do the NELIAC compilers for them. We worked to get the air traffic control people up to speed on Ada and got their software group going. it was keep up with technology, keep the projects going. It was a busy time.

Nebeker:

Was it a hectic time?

Squire:

Throughout my career at Westinghouse, I was there 34 years, I'm pretty sure I averaged 50 hours a week over that period. Some weeks it was 60 hours a week.

Nebeker:

But you got to start at 9:30. [Laughing].

Squire:

Yes. And sometimes I'd get out by midnight.

Nebeker:

[Laughing].

Squire:

So yes, I got known as the night person. I also only lived 10 minutes from the plant so if there was a problem with software late at night you knew who they would call [Laughing]. So I had to keep my fingers in all the different software. Some of my people were like, on AWACS Leo Cosa [spelling?] was on that for many years. And so I had some people who technically reported to me but they worked on projects, they were assigned off. We had matrix management, of course, so you had your project management and they would collect people to do the project and then the line management would develop the technology and support.

Nebeker:

So did you stay in that kind of a position through the years of heading the software group?

Squire:

25 years in management, software management. Obviously I liked it or I wouldn't have stayed [Laughing].

Nebeker:

Right. [Laughing]. Were there any big changes over that period that you saw?

Squire:

From my view they were all incremental changes. In fact, I would generally resist a knee-jerk change or a major change. I could keep my group more efficient if we made a continual small change. So yes, software changed quite a bit over that time. But we did it gradually.

Nebeker:

Now the people in your group did they typically stay there a long time?

Squire:

Some of them, yes, and some got promoted up.

Nebeker:

I know it's usual for engineers to go into management. Did that happen a lot with the people in your group?

Squire:

Over the years in Westinghouse most of the management came up from the ranks from engineering. And that worked pretty well.

Nebeker:

I'm wondering if the stereotype is these young programmers you who do this for a while and then move up to management and so the people doing the coding are young. Was that true in your group?

Squire:

No.

Nebeker:

No?

Squire:

People did the programming all the way up through senior engineers. I did some of it as a A-level manager, B-level manager. The days where you had the scientist and they had the programmer and the scientist would tell the programmer what to do, that's essentially gone. It just didn't work well. It was easier to train the scientist to write the code. Because writing the code is not that hard [Laughing].

Nebeker:

I see.

Squire:

What would happen is the people working on it would learn more and more about the system. So our software people who did the radar control software, they had to really understand how that whole radar worked. And so they grew and got promoted.

Nebeker:

So you said that sometimes people in your group would be assigned to a project. So they would be physically away?

Squire:

Each project would beg, borrow or steal, they would actually get an area of the building and then that radar project would be there and then the different groups would send people in to run and actually build that specific project.

Nebeker:

So it sounds like you worked on a wide range of things, I mean radars and AWACS —

Squire:

We actually did some counter-measures. The APQ programs were electronic countermeasures programs and pods. I worked with Surface Division.

Nebeker:

[Interposing] Select Fire Control?

Squire:

Yes. We did fire control on aircraft. We did torpedo control and torpedoes had eventually very powerful computers in them [Laughing]. I mean that torpedo could track the ship, could decide what kind of ship it was going after, there was a lot of sophistication

Nebeker:

Even distinguish if there are two ships close together, what’s the target?

Squire:

Yes. So there's a lot of software in all that stuff. Your car today probably has 20 computers in it. You just see a wire and you see a little bulge. There's a micro chip in there with a computer in it.

Nebeker:

Yeah I can imagine the defense electronics are just chockfull of computers[Laughing].

Squire:

Right.

Nebeker:

A friend of mine is a statistician at NIH and because of that job he ends up working on all sorts of research projects. It sounds like your job is a little bit like that because the software people are engaged in all kinds of —

Squire:

All kinds. The system engineer couldn't give you a flow chart. So they told you what needed to be done. And so the software engineers had to create the algorithms as well as program it. You had to tune it up, get the timing fast.

Nebeker:

That certainly was the idea early on. Also the idea with the flow chart, you have the intellectual design, you lay it out, and then you turn it over to programmers.

Squire:

And it didn't work because they missed the little things like defining all the data structures. You've got this flow chart but you don't know what the data structures are. You don't know really what it's supposed to do. So typically some of my people managed the software for the projects. What they would do, , the first thing, is introduce them to the system, to the radar system, how it worked, what it did, what the timing was, so it was called top-down. So they started out so that everybody on the project really understood the whole system. And that's why Westinghouse did well

Nebeker:

That's very interesting. I think that's an important point to understand about how these how this work flows.

Squire:

Yes, you can't partition it and have brick walls between the different groups. The information has to flow.

Nebeker:

So how long did you keep at that?

Squire:

Well like I said I was in management for 25 years.

Nebeker:

So you kept doing that until you retired from Westinghouse?

Squire:

Actually I became an advisory engineer when Northrop Grumman bought out Westinghouse. As long as Westinghouse was Westinghouse, I was a manager.

From Westinghouse to Northrop Grumman

Nebeker:

Tell me about that when Northrop Grumman came in.

Squire:

They changed the management. Did some reorganization. Focus changed a little bit on how we were going to do business.

Nebeker:

Would you care to comment on whether it was for the good or the worse?

Squire:

It didn't affect me too much. I was at the point where really I was better off working as an advisor to high level management than managing a group. I was able to use all my experience for that. Some people complained. Some people were happy.

Nebeker:

How did that go, your acting as an advisor?

Squire:

Pretty well. That was interesting work. But then I looked at my future and I found, gee at 62 I can start collecting Social Security. I talked to UMBC. Oh, I can be teaching part time. Hey I'm a double-dipper. Oh, I can do consulting. I can be a triple-dipper. So I am now a triple dipper. I run my own consulting business. PDEforYou.Com. And it's an LCC. And then I teach. I worked for Harry Smith who was our general manager for a while. When he retired he formed a small company, Apex Eclipse. And I worked for them for a while. Rudy Brown, when he retired, he formed a small company, Technical Information.

Retirement

Nebeker:

[Interposing] When was it you retired from Northrop Grumman?

Squire:

I guess it would be '98. Well, no. I was born in '38. I retired at 62. [Laughing].

Nebeker:

Okay so, 2000.

Squire:

I've only got a Master's degree in math. I can’t subtract.

Okay, 2000. I actually started teaching night school I would teach at night at UMBC in '98. That's what it was.

Nebeker:

So you started teaching before you retired.

Squire:

I tended to always plan ahead, to always have a Plan B. So yes, I would teach one course in the evening. And so I had my foot in the door at UMBC. I knew I had a part time job line up when I retired.

Nebeker:

So you’ve had an active retirement, if you want to call it retirement.

Squire:

I'm active with scouts. I'm a Webelos Den Leader and I work with a Cub Scout pack and a Boy Scout troop as Advancement Chairman. I work with the District. I work with the Council. So I'm 20 hours a week with Scouts [Laughing].

Nebeker:

No but I was thinking also of your of your teaching and consulting.

Squire:

[Interposing] Yeah teaching is about 20 hours a week. Consulting is about 20 hours a week. Yes. 60 hours a week still

Nebeker:

But it looks like you're thriving.

Squire:

Grass doesn't grow under these feet.

Nebeker:

You've completed your PhD?

Squire:

Yes. I needed it for teaching at UNBC. The students were calling me Doctor and I thought I'm not going to sit around and say no, no, you've got to call me Mister. It was easier to get the degree. It didn't get me a raise; it didn't get me a promotion.

Nebeker:

What's been especially rewarding in the last ten years?

Squire:

Teaching. I really enjoy teaching. That's the fun part I like. Grading exams I've got a pile of 80 exams at home. I've got 80 students, 2 40-student groups this semester. And that's the harder part but teaching is fun for me.

Nebeker:

And you teach software?

Squire:

Actually I'm teaching computer architecture — arithmetic units and floating point units and control and that. Sometimes I'll teach a course in numerical computation, up through partial differential equations. Sometimes I'll teach a course in graphics, graphical user interface. At one time I taught some programming languages. But then I bring the graphics and the numerical computation and the hardware together through my consulting business. Again, I'm the type of person who makes sure that all the pieces fit together and support each other.

Nebeker:

Wonderful.

Nebeker:

So it's been a very busy time since 2000.

Squire:

Yes.

Nebeker:

I was pleased to see that you're an IEE Life member. Is there any more that, to say about your involvement with IEEE over the years? You did say it started out as the IRE.

Squire:

Yes.

Nebeker:

So you're one of the people who remembers that organization. [Laughing]

Squire:

I was able to give one presentation at an IEEE conference. It had 3,000 people in the audience. And boy is that an interesting experience. And right here we have a room and our local IEEE meets here. And I've given I think two talks to the IEEE section that meets here.

Nebeker:

Is there a student chapter at UMBC?

Squire:

Not as far as I know. One of the reasons is UMBC doesn't have undergraduate electrical engineering. We offer a Master's and PhD in electrical engineering. But without undergraduates you would tend not to have a chapter.

Nebeker:

I'm always interested in the vocational interests of people. It sounds like scouting is something you have given a lot of time to.

Squire:

Yes, because I love working with the boys. My big thing there is advancement and to have them achieve and learn. Our goal is to build the future leaders of America. And so we're training them in citizenship as well as in skills. And we do it by having them have fun.

Nebeker:

Yes.

Squire:

In my teaching I try and make it interesting. When I teach my numerical computation course, the first thing they have to do is program the flight of a rocket. So I take a model rocket and the second class we go out and we fire the rocket. And I say okay now that's what you've got to model. So whatever I can do to make it fun. So, scouting; I still do a lot of computer programming.

Nebeker:

[Interposing] As a consultant?

Squire:

And for my own fun [Laughing].

Nebeker:

Oh. What sort of programming for fun? That's a new concept for most people. [Laughing].

Squire:

I solve 4-dimensional partial differential equations for fun. And lately I've been solving a 6-dimensional one. It's called a neutron transport equation. Math is my hobby too. I combine the math and I combine the graphics and produce interesting pictures. So it's, different.

Nebeker:

Have you kept up the amateur radio activities?

Squire:

No. I built transmitters and receivers and was on the air for a while.

Nebeker:

You mentioned one or two other things that went by me too fast things that you've been involved with in the last decade or so.

Squire:

I'm active with Alpha Phi Omega. I'm a faculty advisor. It's a national service fraternity. I'm also a faculty advisor for the LINUX Users Group at UMBC. These are volunteer jobs; you don't get paid for it.

Nebeker:

How do you feel about LINUX?

Squire:

Oh. I use it on all my computers. I still use Microsoft Windows but when I want to get heavy duty partial differential equations, that’s not what Windows was designed for. [Laughing]. Something like 95% of all super computers are using LINUX, only 5% use Microsoft. And I like programming super computers. Oh, a hobby. I build my own computers. When the first quad core was available, before Dell or HP or anybody sold it, I bought the parts and the motherboard and assembled myself a quad core computer. Well about six months ago, the 12 core computer came out from AMD. So my desktop computer currently is a 12 core computer that I built myself. What I've got is 16 gigabytes of RAM, 2 DVD burners. So yes, computers are my hobby. Hardware and software.

Reflections on Career at Westinghouse

Nebeker:

Wonderful. Are there things I haven't asked about that you'd care to comment on or mention?

Squire:

Not that I can think of. One thing that I thought was great about Westinghouse and that was the management team. George Shapiro would work late and John Stuntz who was the Division manager would come by and be there late. And I'd be around. And so I'd get to deal with him. Johnny Pearson, the engineering manager, I often dealt with him.

Nebeker:

So the evening was a good time?

Squire:

Right. A lot of the bosses stayed around and so I got to meet a lot of the high level management. I got to know Harry Smith when he was a top executive. I spent a lot of time with Dr Paul Pan, worked with Gene Strull over at ATL. So from my perspective we really had a great upper management team.

Nebeker:

That's interesting about the evening being a time to get to know some of those people.

Squire:

Right. A few of those guys like Stuntz would get there an hour before the normal working time but then he'd be there an hour or two after the normal working time. [chuckling] It was the culture of Westinghouse then that you worked long hours.

Squire:

And just before I became a manager, I put in for one hour of overtime to see what it would look like in my paycheck. So, yes, it was the culture; .you got the job done. Very few people were putting in overtime but a lot of the engineers worked overtime. I think the law might get after them these days more but it was really a great working environment. Today I see more and more people switching jobs more often. We had a lot of lifetime employees. They hired into Westinghouse, retired from Westinghouse

Nebeker:

I know a lot of young people feel that it's important for their resume that they have experience at a number of places.

Squire:

Yes. I try and counsel the people and actually cover it in my class: Be sure you work a little over two years at each job because when I was hiring people if I saw somebody who worked a year or not quite two years and then a year and not quite two years, [I thought] “Oh a jumper. Not going to hire him.

Nebeker:

Yes, but in the years of your career people tended to stay at Westinghouse.

Squire:

Right. I don't think I had anybody who left in less than four years and often it was due to a family problem or wanting to go to a different state or something like that. We provided a pretty good environment for the engineers, since all the bosses at that time were engineers. That's what changed when as we called it the MBAs took over.

Nebeker:

Okay. Is that like in the 90's?

Squire:

Yes. Right. [Laughing]

Nebeker:

I knew there was a lot of emphasis on getting an MBA in the 90's.

Squire:

So that and the profit motive. We were talking about the Westinghouse stock price. And I made a comment, oh yes, those guys in Pittsburgh are worried about what the stock price is going to be next month. And one of the managers looked at me, Jon, they're worried about the stock price is going to be tomorrow morning. [Laughing]. So, okay short term thinking. But as engineers we had to always be planning for the next system, we were building this system. What's the next proposal going to be? How are we going to build the next system? So the engineering community always has to look out and look quite a ways ahead.

Nebeker:

Yes. Well thank you so much.

Squire:

Okay. It's been fun.