Oral-History:John "Jack" Nieberding

About John "Jack" Nieberding

John “Jack” Nieberding was born in Baltimore City, Maryland in 1938. After high school, Nieberding won a place in the Westinghouse/ Johns Hopkins Program. He was placed first in the Analytical and Computing Section, where he became interested in developing software programs. When he graduated from the program with his bachelor’s in 1961, Nieberding remained at Westinghouse in the software development section, staying there throughout his career. He later received a Master’s in Numerical Science from the  Johns Hopkins Applied Physics Lab. Nieberding was involved in many important projects – including NASA Goddard contracts, AWACS and Peace Shield – and was promoted to technical director. Although Nieberding officially retired in 1997, he stayed at Westinghouse/Northrop Grumman as a consultant for an additional ten years.

In this interview, Nieberding talks about his education and career at Westinghouse. He discusses becoming inspired to go into software development while in the Westinghouse/Johns Hopkins Program, as well as the need to learn assembly languages and the early days of computer aided design. Nieberding also covers his work with NASA on the Goddard contracts – which eventually led to a proposal for the Hubble space telescope – and his time on AWACS. The various computers and languages he used are also discussed, along with Nieberding’s ideas about the evolution of programming over the years. Nieberding also talks about his choice of usually working on one program at a time, and his decision to remain on the technical side of management with his role as technical director. He also talks about the work of Doug Walters, a colleague, on the NOAA TIROS program.

About the Interview

JOHN "JACK" NIEBERDING: An Interview Conducted by Frederik Nebeker, IEEE History Center, 12 April 2010

Interview #539 for the National Electronics Museum and IEEE History Center, The Institute of Electrical and Electronic 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:

John "Jack" Nieberding, an oral history conducted in 2010 by Frederik Nebeker, IEEE History Center, New Brunswick, NJ, USA at the National Electronics Museum, Linthicum, MD, USA

Interview

Interview: John "Jack" Nieberding

Interviewer: Frederik Nebeker

Date: 12 April 2010

Location: The National Electronics Museum, Baltimore, Maryland

Background and Early Education

Nebeker:

This is Frederik Nebeker of the IEEE History Center. It is Monday the 12th of April 2010. I'm here at the National Electronics Museum to interview Jack Nieberding. Jack, could we begin with where and when you were born, and a little about your family.

Nieberding:

Sure. I was born August 12, 1938 in Baltimore City. I like to say that I was born at Mercy Hospital in Baltimore City, and I've never lived outside of a 13-mile radius circle of that area. So I've been here in the area, either in Baltimore City or surrounding counties all my life. I married a local girl, and I have two children and four grandchildren at the moment.

Nebeker:

What about your father? What did he do?

Nieberding:

My dad was a traffic manager at a trucking company. He was involved with scheduling cargo, particularly between Baltimore and New York. In fact, his trucking company was called Baltimore-New York Express, and they mainly handled cargo going to and from Baltimore and New York.

Nebeker:

What about your early years? Were you always interested in science and technology?

Nieberding:

I was always good in math, and I enjoyed it. Through grade school I went to a local parochial school, Shrine of the Little Flower, and I always enjoyed mathematics and what little science we had then in grade school. From there I went on to Mount Saint Joseph High School, again in Baltimore. During my course of study, which was in the academic area, I again gravitated towards mathematics. And I enjoyed the physics that I took, and chemistry.

Nebeker:

How did you feel about that parochial education you got?

Nieberding:

Outstanding. I'm still involved in reunion committees from my grade school and my high school. And I'm one of those that consider high school some of the best years ever. I still get together with former classmates. I did just this week as a matter of fact, with some of my high school buddies. So one advantage of being in the same area all your life is you tend to have these friends that you've known all your life, especially those that haven't moved away.

Nebeker:

Yes.

Westinghouse Johns Hopkins Program, Analytical and Computing Section

You must've done very well in high school because you got into a very special program. Would you tell us about that?

Nieberding:

Yes, in my senior year I went to the guidance counselor there at high school and I told him I really didn't know what I wanted to do. I didn't know whether I wanted to go to a regular college. I didn't know whether I wanted to go into the military, but didn't have a strong preference in that direction. All I knew was I liked mathematics and science, and I just talked to him about it, and he says, well, there are two programs that you might be interested in. They're both co-op plans in which you go to a university and at the same time you work. So it's like a work-study plan after high school. That way you can get some experience in the real world and see what you like at the same time you're going to school. And if you get placed in these programs, then they will pay your tuition as well. So, that was a benefit, certainly, for my family, because some of the schools - like Johns Hopkins and Loyola - in the area were quite expensive. So, I said, "Okay." I took both tests, and I passed them both. One was where you would work at Black & Decker six months and you would go to school at Drexel, up in Philadelphia, for six months. It was six months on, and six months off.

Nebeker:

I see.

Nieberding:

The other was something called a Westinghouse Johns Hopkins Program, where you would work 32 hours a week at Westinghouse, and they would set up two afternoon classes for you. The rest of the classes you would take in the evening at Johns Hopkins. When I thought about it, I thought rather than six months on and six months off, I liked the idea of doing both simultaneously and at the same time staying local. Johns Hopkins University had, of course, a great reputation. So, I went with the Westinghouse Johns Hopkins program.

Nebeker:

That was specifically for an engineering degree.

Nieberding:

Yes, in fact it was definitely for a BS in electrical engineering from Johns Hopkins. Although I knew it was less in the mathematical area than in specific hardware, I figured that's okay. People had told me, "In the electrical engineering course you're going to get math, and you'll get all aspects of system design, including hardware." They didn't talk much about software in those days, which was new.

Nebeker:

Right.

Nieberding:

The way the program worked was, you were assigned to a particular group for six months, and then after six months they'd rotate you into other areas of Westinghouse.

Nebeker:

To give you more experience.

Nieberding:

To give you experience all around. Of course, for us coming right out of high school, we weren't going to be designing complex radar systems or anything like that. There were about 30 of us for my particular year.

Nebeker:

I see.

Nieberding:

To digress a little bit, with this Westinghouse Johns Hopkins Program I was in Class 5. They'd had four before me. That is, they'd just started the program four years before. And they actually went up to Class 18. Westinghouse had this particular co-op plan for 18 years. And they got many good, young engineers out of it. At any rate, when I was first assigned, just by chance, they happened to place me in the Analytical and Computing Section. This was a section that had just started about six months before that when Westinghouse got their first computer. It was an IBM CPC computer. It took all its instructions from cards, not from internal memory.

Nebeker:

What does the CPC stand for?

Nieberding:

Card Program Calculator.

Nebeker:

It gives you an idea of the times.

Nieberding:

So, Westinghouse got their first computer [at] the end of 1955. I started in June of 1956, right out of high school. I'd just graduated that May, and I immediately started in June. I was placed in this section where for the engineers in this section all of this was new to them, as well, even though they had graduated from college and all. So I was very fortunate, and I had a chance to learn the system along with the engineers. So I felt like I could start contributing right away, because we were all in the same boat.

Nebeker:

Yes.

Nieberding:

We learned computer programming languages. There were assembly languages in the beginning. And then IBM issued their first higher order language, FORTRAN. In fact, I brought the original FORTRAN manual that I learned from that was published by IBM around 1956. So I took the course along with the other engineers, and I just fell in love with the idea of developing software programs with the logic involved and the mathematics involved. Almost immediately from first learning about computers, I said, "This is what I want to do the rest of my life."

Nebeker:

You learned assembly language?

Nieberding:

Yes, because in the beginning, you had to learn some assembly language to run different programs. They didn't have a high order language.

Nebeker:

So you really appreciated having a higher order language.

Nieberding:

Oh, yes, once the high order languages came along, you could really see the advantages of that. When my six months came up, I was getting worried, because I had talked to some of my buddies about what they were doing, and none of it sounded particularly interesting. Many of them were just doing their homework during work.

Nebeker:

Because they couldn't really contribute.

Nieberding:

Couldn't contribute a whole lot, they were just kind of learning. So I went to my boss and I said, "Is there any way that I could continue on here?" And he met some resistance because they really wanted this to be a six month rotation.

Nebeker:

Yes.

Nieberding:

But he convinced them. He said, "Look, our section gets problems from the engineers from all different sections. So Jack will have a chance to see what other sections are doing at the same time he's developing programs to help them." We were developing programs to help design transformers, filters, and other components that went into Westinghouse radars. When the engineer would come to us with some equations, we would then program the equations, first in assembly language until FORTRAN came along.

Nebeker:

So is this the very beginning of computer aided design?

Nieberding:

Very beginning of computer aided design, yes. And we were like a little island there because the engineers had never learned computers. They didn't know anything about it, so to them they wouldn't even attempt to do anything of this on their own. They would just bring the formulas to us, we'd talk with them, go over the algorithms, which included the decision making that had to be done in the programs. So we kind of built our own little empire, so to speak, because the other engineers didn't really know much about what was going on.

Nebeker:

How big was that group?

Nieberding:

We started growing quickly. When I joined there was about six in the group. And then we were eight, ten, and my boss. Wade Etchison was his name. He came to Westinghouse about six months before I started. He was teaching at Hopkins, a course called Numerical Analysis, which was like the beginnings of computer science. It was the study of numerical algorithms, and how you estimate errors and how the errors can influence accuracy and all that. So Westinghouse hired him when they got their computer. He brought along a person, Les Gilman, who was in his class, and Wade knew he would do well in developing computer languages. And then a few other engineers just happened to get in the section when I came in. From that we started growing. Plus, Wade liked the idea of us Westinghouse Johns Hopkins Program members, since we learned programming quickly. So as others came in, he always asked to get some more assigned to his group. So we started building from there, up ten, twelve, before too long.

Nebeker:

Did this influence your choice of courses at Johns Hopkins?

Nieberding:

As best it could. Again, I was locked into the electrical engineering program. That was the deal when you got into this award program. So, for the most part, Hopkins and Westinghouse chose the courses that I would take.

Nebeker:

I see.

Nieberding:

The few optional courses I took, I tended to go more towards other technical courses than mathematics ones. But in those days, there was no computer science. Computers didn't enter into it. We all had slide rules. With a slide rule, you were lucky to get accuracy within a couple of percent of the real answer. They had calculators, little hand calculators that we would use. Monroe and Frieden calculators were used also. Later on, I went on for a master's degree at the Johns Hopkins Applied Physics Lab. I had taken a break for a while, got married after I got my degree, and we had a couple of children. Then I went back. I was working full time at that time. The 32 hours only went for about the first three years until you got what would be called a certificate, which was equivalent to two years of regular day school. At that point, you went on and became a full time employee while you finished out your courses.

Nebeker:

How long did it take to get your bachelor's?

Nieberding:

It took about five-and-a-half years, counting summers. We went all year round, so we would take a course or two in the summer, as well, in the evenings there. I got my degree in October of '61 after starting in the summer of '56. So, it was about five-and-a-half years.

Nebeker:

I'm impressed that you worked almost full time for three years and then full time. That's quite an achievement.

Staying at Westinghouse, CPC

Had you decided that Westinghouse was where you wanted to stay?

Nieberding:

Yes, I really enjoyed the people and the work. I was fortunate my whole career in that I had very good managers.

Nebeker:

So you stayed in that section.

Nieberding:

Yes, I stayed in that section essentially the whole time. It changed names over the years, but essentially I was always in a software development section. There were systems sections, radar engineering sections, advanced development, things of that nature. But I stayed in what was one of the software development groups. I happened to be in the West Building, also called Surface Division. There was an East Building, also called Air Arm or Aerospace. They had their own software sections. When Wade Etchison retired, he turned it over to another manager in the group and so on, and I just kind of stayed pretty much there, my entire career.

Nebeker:

How did it go with the computer development? So you said you started with the CPC.

Nieberding:

Right.

Nebeker:

Was that easy to use?

Nieberding:

No, it was difficult. Well, it was cumbersome, I shouldn't say difficult. You had to generate punch cards in which you would put the instructions to the computer, and since the instructions weren’t stored in memory, the computer had a card reader to read the instructions from cards. It would read the cards one at a time, taking its instruction from there. The CPC had a little bit of memory for storage of data. So an instruction might say something like, "Add A to B and store in C" and it would go get A and B, add them, and then store it in C. Then it would move on to the next card for its next instruction.

Nebeker:

So it was moving through the program as it executed it.

Nieberding:

Right. So if you had a loop that you wanted to do, let's say of ten iterations, you would actually reload the same cards ten times or reproduce the cards. We had a card reproducer sitting in the computer room. So after you typed up the cards for the loop one time through, for ten times you might reproduce those cards ten times, and then stack them one behind the other, and run them through.

Nebeker:

Yes.

Nieberding:

Of course, when you dropped the cards, that wasn't so good. So you would number them. We only had the CPC for a short time.

Stored Memory, Flowcharting and PDL

One of the first stored program computers came out from IBM called the 650, the IBM 650. When we started off we were actually in a small building on Wilkins Avenue in Baltimore because they were building the building down at the airport that we would ultimately go into. It would be the called the West Building or the Surface Division. As soon as they completed that building, we were able to move into it at the same time they got their IBM 650 installed. Then we had the advantage of actually storing the instructions in memory, so you could store the do-loop once.

Nebeker:

That's what I remembered: the program deck being read all at once.

Nieberding:

Actually it read it one card at a time.

Nebeker:

Well, I was thinking in the mid-'60s.

Nieberding:

Yes, with the new computers you'd read the deck all at once because it was all stored in memory. Prior to that on the CPC it actually read each card and executed whatever was in that card. If there was a decision point, you would say, "If one condition was true, you'd execute one instruction on the card; if it's not true, you'd execute a different instruction on the same card."

Nebeker:

I see what you mean by cumbersome.

Nieberding:

We were very happy when we went to stored memory. Now you could read everything in, and now you could jump around and everything would be there, in memory.

Nebeker:

What about the work that you were doing with that group? You said some of the things that you were doing helped you design filters or transformers. How did that work go in those years?

Nieberding:

What we would do put us pretty close to the hardware engineers. When they had some transformers to be designed, or filters to be designed, or any other computing needs, they would come to us.

Nebeker:

I see.

Nieberding:

Then we'd sit down with them, we'd go over the problem. We'd usually draw up flowcharts, as they called them, which was a way of trying to show that you understood everything that was to be done. Because on the computer you had to account for every error condition that could occur. So, when you sat down with an engineer you might say, "Well, suppose this happens?" And then it might be something that he'd never thought of, or something that shouldn't ever happen, but the computer expected to be told every path to go through. So the flowcharts were a handy way of showing all the decision points, what had to be done, so you would sit down with the flowcharts as part of the analysis phase of the job.

Nebeker:

How long, in your experience, did that last, the flowchart as a way of planning a program?

Nieberding:

It lasted quite a while. Especially those of us who kind of learned it early on - we found it was a very helpful tool. Then, at some point, I don't remember exactly what year, we switched over into what they called program design languages, PDL. What you would do is you'd use FORTRAN not to solve the problem, but to define it. You would use the same “if/then/else’s”, you would use the same "do’s” and that. But it would be more writing in a readable English language, like “if the voltage is between such-and-such a value, then do the following, else do something else.” And so forth. So it was a handy way of designing, because you could write it [in] readable English language, and then you could sit down, again with the engineer that gave you the problem, and go over it and say, "Now, is this really what you intend?" And it was easily understandable. From there, ideally, what you could do is use those as comment cards in the final program. So, now, a comment might be “if the voltage is between such-and-such,” and you'd mark that as just a comment, then you'd write the actual code, say in the FORTRAN language, that would be, “if A,” the name of the variable, “is greater than a number,” and so forth. If something wasn’t working right, you could go back to the engineer and say, "Let's go over this again. This is the problem as you defined it. This is how it is implemented." You could see where something may have gone wrong. So, the PDL was a very convenient tool. Once we started using that more frequently, we kind of got away from the flowcharts. But from a graphic representation, showing lines, it was easy to follow a flowchart.

Nebeker:

I learned flowcharting, and it just seemed to me that that art faded into the past.

Nieberding:

It did. Some of us still occasionally used it; we had our little templates, with all the little different kinds of boxes such as a diamond shaped box which is a decision box. But, yes, then the PDL took over.

BASIC, Goddard

Nebeker:

Something you wrote interested me. You said that when BASIC language came along that many engineers started doing programs themselves.

Nieberding:

Yes, that was a big turning point for us. We were used to the engineers coming to us with their problems, and that was the main charter for our group - just support the engineers. There's plenty to do there, they need help designing radars or electronic countermeasures equipment, things of that nature. Well, then BASIC came along.

Nebeker:

Was that in the '60s? I don't remember now when BASIC -

Nieberding:

Early '60s. Let's see, we went down to NASA around 1966. So, yes, early '60s is when we started noticing that for one thing, the engineers found out how enjoyable it was - if enjoyable is the right word - to develop their own programs. They saw how much fun we were having. So to speak. Since they were also engineers, and were thinking logically from hardware design experiences, it seemed fitting for them to get into the software end of things. So, when the BASIC language came out, it was even easier to learn than FORTRAN. Any little computer that came along had BASIC on it. So, the engineers started using BASIC to design their own programs.

Nebeker:

Yes.

Nieberding:

They'd have equations, and they would just program their own problems. At that time, Wade had retired, or had gone into more of an advisory position and Tony Frezza was our manager. Tony recognized that we were going to be out of work soon. So he got the okay to go out and talk with people from the NASA Goddard Space Flight Center, which is just down the road in Greenbelt, Maryland. And in 1966, he got us in the front door to help develop software for Goddard, which was responsible for many small scientific satellites. Johnson Space Center in Texas had the manned missions, but Goddard had many responsibilities with small scientific satellites and communication satellites. The weather satellites were NOAA, and I'll talk about that in a minute. But we started off by developing software for Goddard to support some small, scientific satellites.

Nebeker:

Was this a contract?

Nieberding:

Yes, it was a contract with them. We bid on it, and fortunately they had a technical officer down there named Jerry Hahn, who had heard about us, and had worked some with us. There were some field services groups out of Westinghouse that had gone down to help in various support capacities around Goddard; just helped operate spacecraft and do maintenance, the odds and ends. Nothing of developing software or hardware or anything of that nature. So Jerry had heard about us, and so he came and talked with Tony, and then we submitted a proposal and we won. We went down there and started using their own computers, and whatever language - I think it was FORTRAN - they were using. That they already had this equipment in place. Then, they decided, Goddard that is, to upgrade their control centers. They had a control center called MSOCC, for Multi-Satellite Operations Control Center.

Nebeker:

Were they actually controlling the satellites out of Goddard?

Nieberding:

Yes. After launch. Others are responsible for launching. Then Goddard was responsible for health and safety of the spacecraft. So they continually monitored the spacecraft. Also, they would collect scientific data.

Nebeker:

So they're also controlling that data flow.

Nieberding:

Right. In those days, you didn't have all the communications satellites you have now, where you can watch every satellite 24/7, round the clock. In those days, you had to wait for these orbiting satellites to come around. Approximately every 90 minutes they orbit the earth at the altitudes they were placed. Then you had just a few ground stations around the world. So, when the satellite came into view of a ground station it would usually only be for six to eight minutes. In that time, Goddard was responsible for making sure that they downloaded from the spacecraft any scientific data that was collected from the last time plus upload commands to the spacecraft so that while it's out of view it's able to execute commands to collect additional scientific data. In those days, things had to be pretty precise. The control centers would be real busy, they'd have countdown clocks, and they were ready. If you missed a satellite pass, you would have to wait for the next time around. There were several ground stations, so if you missed one, you might be able to get the command data to be uploaded down to another ground station that might see it in a half hour or something like that.

Nebeker:

Do you have an idea of roughly how many satellites Goddard was trying to manage in those years?

Nieberding:

Well, over the course of about 14 or 15 years, we did about 16 ourselves.

Nebeker:

I see.

Nieberding:

Now, the Multi-Satellite Operations Control Center got that name for multi-satellites. They were responsible for the small satellites that weren't big enough to have their own control centers. Some of the satellites were bigger. They would have a dedicated control center.

Nebeker:

I see.

Nieberding:

Multi-Sat got all the small ones. There was one where they launched a frog up into space to see what would happen. Some other things like that. Experimental ones. Ones looking for x-rays or gamma rays coming from space. What really worked out well for us is that after we had been there and successfully implemented software for a couple of their small satellites with their old system, [that’s] when they decided to upgrade, [and] that's when we went and submitted a proposal to install commercial equipment. There we used Digital Equipment Corporation's VAX computer. VAX computers had just come out.

Nebeker:

I know it was quite an advance.

Nieberding:

It was high speed, and Digital had a good reputation. NASA was impressed with them as well, so they were very happy that we had bid those computers. We bid to not only buy and supply these commercial computers, we also bid to integrate them into the control center there. So we got some of our hardware people involved in integrating it.

Nebeker:

They already had some mainframe computer there that was their main computer?

Nieberding:

Yes, XDS, old Xerox Data System computers that they were removing. They had just gotten too old and too slow. So they were removing all of these. We were now going to put the new VAX computers in. Digital was into the smaller computers, but what Goddard was finding is that, for real time applications, it was better to have several of these - I won't even call them small, because they were sort of midsize at that time.

Nebeker:

But still much less expensive than an IBM mainframe at the time.

Nieberding:

Right. Plus, if one failed, you had others. You could switch between them. With how they had to operate the satellites, they wanted backups in case one went down, you could immediately switch to the other. So we got that contract, we selected the computers and the numbers of the computers, and we integrated them into the control centers. Then we wrote the software from that point for the other about ten or so other satellites that Multi-Sat was going to support. Then, having done that for a while, one of the bigger satellite series called HEAO, for High Energy Astronomy Observatory, came along. They were large enough there was going to be three in that satellite series, an A, B and a C, that they got their own control center. We bid on that, and we also won that one. That was all, again, interesting work.

Developing Software for Larger Systems and NASA

Nebeker:

I believe that was a time when people were figuring out that software could be enormously difficult to carry out with larger systems, that writing large programs took longer than expected and created more problems than expected. How did the work go that you were involved in?

Nieberding:

NASA, especially the people that we dealt with down there, Jerry Hahn and his team, were very knowledgeable in the state of the art of computing. NASA had a DARPA program that actually was the beginning of the Internet, too. So they had some guys that were pretty far ahead in their thinking. To keep up with them, plus what we were learning on our own, we started into structured programming. We had Ed Yordan who was one of the top teachers of structured programming at that time. He and his company came in and taught us about structured programming, and how to use FORTRAN to help eliminate the common errors that one would run into.

Now our team had been pretty thorough and had good quality control up to that point, but even more so now that we switched over into a structured programming mentality. So we designed the NASA work that way, and NASA was very happy. We kept them in the loop at all times with what we were doing. After that we actually helped them out in some of their Internet related activities, such as packet switching, sending messages all around the different networks. So we got to a high state of the art. It was a real plus of our work there at NASA/NOAA, as I mentioned in the write-ups, even though it didn't support Westinghouse equipment, per se, radars and ECM equipment, and so forth. We learned from them, from dealing with people that were really interested in the state of the art of computing and networking and systems and things of that nature. People went down there, learned quite a bit about real time, multi-processing systems. When they came back from NASA, they were able to use that technology and their experiences to help run Westinghouse type equipment.

Nebeker:

Now when you were working on that contract for NASA, was that your entire work in those years?

Nieberding:

For me personally, yes. I was the technical director of the teams of people that were working on that.

NOAA and TIROS

Then Doug Walters, who was also in our section, led a team that went down to NOAA, the National Oceanographic and Atmospheric Administration, which was in Suitland, Maryland. That came about because of the good work we did at NASA on some of the satellites. It turns out that some of the people from NASA that were involved with the TIROS program knew about what we had done. They were having some troubles with their own contractors and getting things done. So, they told Westinghouse, "Why don't you bid on this?"

Nebeker:

On the NOAA work.

Nieberding:

Yes, this NOAA work for the TIROS satellite. We did. We put in a good proposal, and we won. Then Doug and his team at NOAA that included some of the people that had been on my team - we were doing some things in parallel here - Doug and his team developed the software for TIROS and parts of the activations and evaluation phases of that program. It really helped NOAA, because they were worried about missing launch because of not having software ready and not having testing complete. His team did a great job, and they got it done on time.

Nebeker:

To establish the chronology: you were technical director of the Westinghouse team at Goddard from 1968 to 1981, and you worked for NOAA after that?

Nieberding:

I think some of it was in parallel and Doug was technical director on all of the TIROS work.

Nebeker:

I see.

Nieberding:

Doug had given me some material. I made a copy for you. 1975 was when we first got involved with NOAA. That's when they were getting ready for TIROS. They were having some problems, and they were worried about meeting launch. And that's when they ask us to get involved.

Nebeker:

I see.

Nieberding:

Doug Walters is sorry he couldn't be here. Originally, he was also going to be here with me, but he was involved both today and tomorrow and couldn't make it. I talked with him and he did give me that material. So there was some parallelism there. As we got near the end of our work, they were getting into theirs.

Winning Contracts, Upper Management Opinion

Nebeker:

<flashmp3>539 - nieberding - clip 1.mp3</flashmp3>

Looking back on all of this [with] NASA, you were able to do what you contracted to do, and the things worked?

Nieberding:

Absolutely, and it helped us win follow-on contracts. We came in with a rather high costing rate. That was one of the problems that we had had from the beginning in trying to bid against these various small contractors around the Beltway that are designed to try to win jobs with NASA and the government. We were required to use the same costing rates as the rest of Westinghouse up here at the airport where their normal dealings were with radar contracts and things of that nature. So in order for us to have a chance, we really had to do an extra good job. Fortunately, we had the help of the people at NASA and then later at NOAA, who really liked what we had done. They went to bat for us. They said, "Look, even though these guys are more expensive at first glance, they're going to get the job done right. The other contractors come in with lower bids, but it ends up costing more in the long run because it doesn't work. You have to put more money in, bring more people onboard, and Goddard's got to be more involved, to micromanage them." We really appreciated that because on the basis of cost alone we wouldn't have made it. We couldn't out bid them, based on the costing rates we had to use. It was just our charter.

Nebeker:

How was that work regarded by upper management at Westinghouse Electronics? I can imagine they might think, "Hey, here's a great way to expand by doing the contract program."

Nieberding:

Yes, but initially not as much as you might think. A couple of the managers were concerned that some of our best software engineers were involved down at NASA/NOAA, and not specifically supporting new or updated Westinghouse equipment, which was the bread and butter of Westinghouse. Fortunately, the managers that I had went to bat for us, and they were able to say how important this work was. Plus, they weren't hurting when supporting the other programs. They had hired other people and other engineers. Plenty of software engineers were now coming out of the colleges and the universities.

Upper management did like it when we won awards. We won a couple of awards there, and I think they were very proud of us. I think we turned the corner there on showing them that this work was important. It gave Westinghouse and later Northrop Grumman a good reputation with the communities out there. Something we could show in our proposals, because real-time software is difficult software to write.

Algorithms, Numerical Science Master’s

You are getting data in at a very rapid rate, and you've got to process it quickly. You don't want to lose data because there could be something very important there. We're not talking commercial systems, or banking systems, or something like this. You need very fast computers. You need to write good, tight, efficient code, so that you don't lose any data. Sometimes you have to compress the large amount of data being received in real time.

Nebeker:

At that time was there an emphasis on having the most efficient and fastest algorithms?

Nieberding:

Yes. Almost always you were faced with the fact that you were getting more data coming in than what your computers could handle, unless you were really efficient. You just never seemed to be in a comfortable position. Whenever you got a faster computer installed, invariably the application was more complex and required even faster processing. I don't ever remember on any of the NASA work when we say, "Oh, we got all the computer power in the world, it's an easy job." It seemed like you always had to be very mindful of writing good, efficient code. Sometimes you had to use compression algorithms.

Nebeker:

The data is coming in compressed form?

Nieberding:

To minimize the amount of data you actually process, you used compression algorithms on the raw input. So, yes, we used a lot of good analysis, a lot of good mathematical algorithms, in order to accomplish this.

Nebeker:

I noticed you got a master's degree in numerical science. Can you tell me about that?

Nieberding:

Again, since my bachelor's was in electrical engineering, and since I was spending all my time in computer science related work, I went back to Hopkins and looked at the various masters programs. At that time, they did not have a computer science master. This was still a new area. But they had something that was as close to it as you could find. I told you my boss initially came from teaching a numerical analysis course at Hopkins, and that happened to be one of the courses. Again, these were courses that would ultimately lead to things that you needed to know to do good computer science programming and design. But they didn't call it computer science. The closest thing I could get to something that was computer science was called numerical science.

So I started taking the courses. There were five. For a masters degree you needed five year-long courses. Because I was still raising a family, I took one course a year in the evening. You were allowed five years to complete your master’s, and that's what I did. Well, in my third year, Hopkins finally put in a computer science program. That had a few more courses than the ones I had taken. I tried to switch my master’s program over from numerical science to computer science, but they would have required me to take a couple of extra courses. And again with the raising the family and all, I just went ahead and got the degree in numerical science.

Nebeker:

Perhaps a digression on that term. I know in the early years they talked about numerical machine control, numerical weather forecasting, which meant essentially computerized weather forecasting.

Nieberding:

Yes.

Nebeker:

Now did that numerical science essentially mean application of computers?

Nieberding:

No, it was number theory. Statistics.

Nebeker:

Numerical analysis?

Nieberding:

Numerical analysis, yes. Again, it was helpful in developing algorithms that would ultimately be on the computer, because it would take into account things such as the significant figures that you had available to you in the computers, and what would that mean, ultimately.

Nebeker:

The efficiency of the algorithms.

Nieberding:

Yes, build up of errors, and when did you reach the point where the errors have built up so much that your results are almost meaningless.

Nebeker:

Yes.

Nieberding:

So you had to figure out the best way to tackle an algorithm so that you would maintain significance as far along the process as you could. That kind of thing. Yes, this was numerical analysis. There w[ere] some courses on database structures and on setting up databases that were computer oriented. Also, theory of statistics, which gets into some statistical distributions using advanced calculus to do some statistical analysis. One of the guys I was taking that class with was actually using that, as he was an electrical engineer, in some of the engineering work he was doing at the time.

Nebeker:

So for simulations.

Nieberding:

That kind of thing. But it was more from the standpoint of integral calculus. In other words, setting up a frequency distribution and then integrating it over a certain period of time. Monte Carlo methods would be one way to solve it, but this particular course concentrated more on setting up the algorithms using integral calculus.

Hubble Proposal

Nebeker:

What happened when that contract ended with NASA? Did you then work on some Westinghouse projects?

Nieberding:

Yes. So we did the HEAO work that I mentioned to you, where we developed software and integrated new computers into a new control center to support the three satellites for HEAO. After that, Doug and his team were still working down at NOAA for a while longer. I don't know when their work ended. Anyhow, we tried to bid on the space telescope project. At that time, the Hubble Space Telescope was coming along. Things were changing down at the NASA arena and at Goddard. We were worried about the fact that, at this time, we would have to be low bidder. We no longer could win a big contract with our reputation alone. It was going to come down to low bidder.

Nebeker:

I see.

Nieberding:

We unfortunately made some design decisions on what should be in the proposal to try to reduce costs, and it didn't work out so well. Goddard felt like our proposal wouldn't accomplish what they wanted for the size, numbers of the computer, sizes of the computers, and that. It was probably about time to return to Westinghouse, as there was interesting things going on back here.

Nebeker:

Were you behind that proposal?

Nieberding:

I helped with the proposal. We all got in there. We had been told that we were going to have to be low bidder. There was no way around it. We could not rely on our reputation from the small satellites.

Nebeker:

So you had to get the price down.

Nieberding:

Yes, we made lots of cuts and it hurt our proposal. I think there was so much work going on back here that upper management was just as happy to bring our people back.

Nebeker:

I can understand that - well trained people in a technical area that's in demand.

Nieberding:

Right.

AWACS, Peace Shield, Red Team/Blue Team

So I came back, and I was fortunate that when I came back, there was a new part of the AWACS program about to start. Westinghouse has had the AWACS program for a long while, and they had a very good update from a technical standpoint coming along called RSIP, for Radar System Improvement Program. We were updating one of the computers we were responsible for, and one of the monitors, to help with the command and control of the AWACS airplane. So I came back, and they asked me to be a technical leader on one of the aspects of that.

Nebeker:

Another item in your CV. You were technical director for the air defense [systems] from 1985 to 1989. What was that effort?

Nieberding:

For Peace Shield. Westinghouse had a foreign defense system. We did a lot of systems for foreign air defense, in which we supplied the computers, in some cases the radars, and also the software for some of those. Peace Shield was a big one.

Nebeker:

So, Westinghouse had a contract with another country to produce part of an air defense system.

Nieberding:

Yes, to do a whole air defense system. So they had me as technical director on that particular phase of the work.

Nebeker:

I see.

Nieberding:

Again, very interesting. We were using structured programming techniques, all the latest and greatest, and on the latest and greatest computers.

Nebeker:

Is that something Westinghouse has done a lot of, producing systems for other countries?

Nieberding:

Air defense systems, yes. For foreign countries as well as for our own.

Nebeker:

Of course I know about the work for US defense.

Nieberding:

The two different buildings: the West Building was also called Surface, the East Building was called Aerospace. The East Building tended to concentrate on putting radars in planes and upgrading those, the ECM pods, and things of that nature. That was their charter. The Surface division was more for ground based air defense systems. Since I was in that group, I tended to be more involved with that. Although AWACS was a little different, since that was an aerospace application. Besides the Peace Shield program, there was also one done for the country of Jordan. In fact, what we did was to develop standard software that could be used on both projects. Again, we used techniques such as structured programming and database-driven software and trying to write it as general purpose software so that it would be portable from one system to another.

Nebeker:

How did that work out?

Nieberding:

Very well. To a point, and then one project started to get a little behind. So they had us split off after a while. We did go down the road together through a design phase, and then it split off some. That was fine. We did have a lot of commonality that got us through the design phase of both.

Nebeker:

Could you explain this red team/blue team business?

Nieberding:

Yes. When a proposal is complete, before submitting it to whoever requested a bid from you, a red team will go through the proposal very critically. They will read it like they were the customer, and mark it up and say, "Hey, this is weak here," or "You should add this, you should add that." A blue team, in some cases it is the same team, will actually make the changes, rather than just hand it back to the people that generated the proposal and make them do it. The blue team will roll up their sleeves and get in there and help out.

Nebeker:

I see.

Nieberding:

I have done both. For a red team, sometimes you get some of your best people to come in for maybe just half a day, or whatever their managers can spare them. They come in, they read, they mark it up, and then they hand it off. They then go back to their other job. In other cases, the person responsible for the proposal, the proposal manager, will kind of beg the other manager, saying "Please, just give me such and such a person for a day or two, or a week, to complete this. He had good views, but I'm not sure the other people can implement it as well as he could if he just sat down and did it."

Nebeker:

I see. What was the nature of your work in these years, the '80s and much of the '90s? Are you involved in different projects at the same time, or one project at a time?

Nieberding:

By choice, I was typically on one program. I like to concentrate on one project. And my favorite role was always technical director. I liked having a team of good people that I could rely on. Then we would focus on a particular project. Now, sometimes it couldn't be helped, like when we were doing this commonality with the Jordan system and the Peace Shield system. I had to float back and forth just to make sure everyone's going down the same path. But most of the time I was assigned to a specific project.

Nebeker:

If we look at your work from 1985 on, there was Peace Shield and then there was RSIP.

Nieberding:

That's AWACS.

Nebeker:

How'd that AWACS project work out?

Nieberding:

It went very well. We had some very knowledgeable customers - pilots that were actually going to use it. They made sure that what we gave them was really user friendly, because they had to use it.

Nebeker:

It was good that you had them involved at that stage.

Nieberding:

Oh, yes, and we had a good reputation with them. They came to the design reviews that we had, and they were tough on us, as they should have been. But we worked with them, and they were ready to work with us, to roll up their sleeves. So it went very well, and they were very happy with it. Later, after I left, they even updated it more for a color display, and they added some more bells and whistles. So it's continuing. Today, we're constantly upgrading it with new AWACS equipment.

Nebeker:

I see.

Technical Director, Retirement and Consulting

Were you still doing coding in those years or were you manager?

Nieberding:

Mainly at that time, I use the term “technical director.” I never actually, by choice, got into management.

Nebeker:

I see.

Nieberding:

Along the way, there were always choices. You start off assistant engineer, then engineer, then senior engineer. The next promotion from senior engineer is where you either go to management, as a supervisor or manager, or fellow engineer, staying on the technical side. I always wanted to stay on the technical side. I didn't want to get in direct management of people. Now, I liked being technical director, but there you're kind of managing but on a technical level. You're not hiring, firing, and giving raises. That people kind of thing. I was more interested in the technical end. So I stayed on the side of the ladder where I went to fellow engineer, then advisory engineer, then senior advisory engineer. It came up to retirement time when I hit 58. I had certainly had more than the 30 years necessary of experience. That's when I decided for reasons of rolling over the pension plan, it was better for me to retire, roll over the pension, and then come back as a consultant. Of course, before I did that, I worked it out with my boss and everything was fine. It was as if I had stayed on.

Nebeker:

I see.

Nieberding:

I retired to get that lump sum pension, and then come back in as a consultant.

Nebeker:

That was in '97 that you did that?

Nieberding:

Right.

Nebeker:

So there was no break really in your employment?

Nieberding:

No, in fact, I retired one morning and came back that afternoon as a contractor.

Nebeker:

That was your retirement. [Laughs]

Nieberding:

Yes. The reason was that they were just starting an air defense system, well continuing an air defense system, for Thailand. I had gone to my boss and said, "Look, if I stayed here as an employee, I'd be assigned to the Thailand program anyway. I'd like to retire and then come back as a consultant and do the same exact thing with Thailand." He said, "Fine." And I talked to the Thailand program manager, and he was fine with that. He said, "But I need you right away." And I said, "That's fine." It was like February something - it wasn't like I needed a month away or anything like that. I went out in the morning and came back in the afternoon with a different badge. I went right on and finished up my career just as if I'd stayed an employee.

Nebeker:

At the same office?

Nieberding:

No, a different office, not as nice. I had the nicest office right up the street here. It overlooked a fountain and a pool and all that. But that was fine.

Nebeker:

In retrospect, was that the right decision, do you think, to retire and come back as a consultant?

Nieberding:

Well, the market immediately dropped after I rolled over all this money. But it would've probably happened anyway. Again, it made no difference.

Nebeker:

It didn't make a difference in your relations to management?

Nieberding:

Not at all.

Nebeker:

Or with coworkers at Westinghouse, or rather Northrop Grumman at the time?

Nieberding:

It didn't seem to. I guess in the end to say I would've actually worked as a full time employee for 51 years as opposed to, what it was, 40-some as a regular employee, and the last ten as a consultant, it would've probably been nicer just to say I'd been an employee the whole time. But except for that it didn't matter.

Nebeker:

Working conditions were the same?

Nieberding:

A smaller office, but that wasn't a big a deal.

Nebeker:

Relations with the others?

Nieberding:

That was fine. They understood what was going on, and I was moving to a new program. I'd stayed on the technical side all along, so whether I came in as a consultant or as a senior advisory engineer made little difference. At least to my face they didn't say anything.

Nebeker:

Was this a common arrangement at Northrop Grumman or Westinghouse?

Nieberding:

I know others. The group that I went with was called PYXIS. This was a group of others that had left Northrop Grumman and came back in as consultants. So they already had a vehicle by which they would do this.

Nebeker:

I see.

Nieberding:

These were people, either they had been downsized or they just wanted to leave on their own. Maybe they came from another company. It was primarily other retirees. There were others that had done it, and so they had a contract available with Northrop Grumman that would allow them to do this.

Nebeker:

I see. Would they work with other companies besides Northrop Grumman?

Nieberding:

Not in the beginning - now they do. Northrop has changed some of their policies. For them to supply people to Northrop, they have to go through another third party who has contracts with corporate Northrop Grumman. This contract was sort of at the local level; I mean they all knew us. But things have changed there. I have retired from them. They now do software evaluations for different companies around the country. They have almost no presence in Northrop any more.

Nebeker:

How did that work go? You said it was for Thailand that you were doing it for?

Nieberding:

Yes, Thailand, air defense system. It was very similar to what we had done on other projects.

Nebeker:

Yes.

Nieberding:

I didn't get a chance to visit Thailand, out of it, but that[’s] just how it worked out. But, yes, that went well

Programming Evolution, Ada

Nebeker:

How has the programming world changed over the years? I can imagine that it was very different from the '70s to recently, when you retired. Can you give us some kind of overview of that?

Nieberding:

Well, in the beginning, you were really dependent on your super-programmers, your people able to do their own quality analysis and to do their own debugging. Desk debugging we used to call [it], where they went through and visually tested every loop, and all of that. Structured programming came along because there started to be so many people programming, some of them not as good as others. Maybe they weren't as thorough in their testing. It would get to the system level, and you might not notice certain problems. Other problems would occur after the systems had been sold off, or were out in the field.

Nebeker:

Yes.

Nieberding:

Now they wanted to give software the same treatment, at least as good as hardware, in the way they had quality control and testing techniques. So it then really came around to where we had so much quality control, you really had to add that to the cost and time of your jobs. You had to make sure you had enough time in there to test really thoroughly everything that's being done. Setting up test programs and having your good quality control people, looking over and making sure things were fine. Also, Ada was a big change. The government decided FORTRAN wasn't stringent enough in the way you define your programs. They wanted something so stringent that just to get the program to be compiled through the compiler it meant you had a very good chance that it was going to work. Because there were just so many rules that you had to follow. So it became more restrictive in that you had to learn these techniques. It took you much longer to develop programs.

Nebeker:

So then the developers went from FORTRAN to Ada as the principle language?

Nieberding:

Yes. What happened was the Department of Defense started requiring Ada on their contracts. We started noticing it on anything coming out of the Department of Defense. They had decided that FORTRAN had weaknesses, that it just didn't have enough of these stringent requirements or constraints placed on you. So they went out and got bids from different companies to supply a language that would be, again, detailed and restrictive in what you could do. With FORTRAN, you can sometimes trick things to get things done. But they wanted something where there was not really a chance of that, where you really had to follow the rules and the compiler would catch any violation of those rules. I think three different companies submitted proposals, and this one company submitted one that became Ada.

Nebeker:

Okay.

Nieberding:

That's where you got into class definitions. Now, they've gotten away from requiring Ada because there were some issues. Again, it's so complex that getting enough good people that know Ada, and getting it integrated in a timely fashion was a problem. For real time, it had to be fast. So many of them have gone back to languages like C and C++, which are very basic kinds of languages. So it's not quite as stringent now. But, that was a big change.

Nebeker:

Was that a good change, in your view, for the Defense Department to require Ada?

Nieberding:

Probably not, in my opinion. Although I can understand what went behind all this, there were so many programmers out there, and not all of them were necessarily good. By putting all these restrictions in, you can at least get them probably on the right path. But it did slow down some others who would be capable of doing things on their own. From their standpoint, I can understand why they would want to get something more restrictive.

Nebeker:

But it seemed to slow things down.

Nieberding:

In my opinion, it seemed kind of slow to develop programs using Ada. It just seemed difficult to do. You had to have so much interaction between people. Everybody had to know what was going on there, which isn't necessarily a bad thing, but not to the nth degree, in order for programs to work together. Again, I can understand where the government was coming from in this. So, as opposed to nothing at all versus that, I would go with Ada. It just seems like there would have been something in between. I think it was probably the ultimate downfall of Ada that it was just so complicated, so expensive. Doug told me that he thought that the lack of the usual supporting software, or the expense of it due to not having wide-spread market drivers to make it profitable to generate, was also a major contributor to its downfall.

You know, they used to - and probably still do - talk about lines of code per hour as a gage of cost. And you could talk about, "Oh, I can write ten FORTRAN lines of code in an hour." Well, Ada might be a half of a line, because so much had to go into it. Now, granted, when all was said and done, it might take you longer to debug those ten lines, and that's why I say there were tradeoffs there. All I can say is that the fact that Ada is no longer required would tend to make you think that maybe they went a little too far there. I saw some of the updates that they made to FORTRAN, and I thought they were pretty good.

Nebeker:

So the problems might have been addressed by improving FORTRAN?

Nieberding:

Yes, without changing the paradigm as they like to say, completely.

Large Software Projects

Nebeker:

Another general question. I know that large software projects have sometimes been complete failures. A hospital, for example, that implemented a system and then had to give it up because of all the problems and the difficulty of fixing them. Were there any major failures at Westinghouse Electronics? Any system where the problems were so intractable that they gave up on the system?

Nieberding:

Fortunately none of the ones I was involved with.

Nebeker:

That's very nice. So everything got pushed through?

Nieberding:

Got pushed through and frequently on time and even within cost. Frequently, just frequently. But yes, I think we did pretty well. Again we had good people. Good software engineers, good thinkers, and good designers.

Nebeker:

I imagine that over the years the programs in this area, like elsewhere, got bigger and bigger. And the management of a software project must have gotten noticeably more difficult.

Nieberding:

Oh, yes. I was always glad I never drifted to the management side. Although even being technical director -

Nebeker:

Yes, you must have seen the difficulties.

Nieberding:

Trying to report software progress, it's still very difficult, always has been. In other words, they would ask, "Well how far along are you? Are you 90 percent finished?" Invariably it would be, "Oh, I'm just getting started, so I'm maybe ten percent done." Then, a little bit each week, and pretty soon you're at 90 percent, but then you're really not. Then it becomes 92, 93 - and then you're at 95, forever, you know, trying to get that last little bit.

Nebeker:

I see.

Nieberding:

Because things happen. All of a sudden, there's a conflict in programs or interrupts happen at just a certain time where they interfere with each other. As I say, real time, multi-processing systems are difficult to implement. You've got data coming in you've got to process. Meanwhile, there's other things going on, and you're still processing previous data. Users are typing in commands that you've got to respond to quickly. Lots of things going on, and as the systems get more and more complicated, more and more interactions can occur.

Nebeker:

We should be surprised when these big systems work.

Professional Societies, Presentations, Databases

What about your involvement with professional societies? Have you found any of these engineering societies important to you?

Nieberding:

In the beginning, some of the DEC [Digital Equipment Corporation] societies were good. We were using a lot of DEC computers. I mentioned the VAX. There were DEC PDP 11s before that, so we used a lot of their equipment along the way. Prior to that I went to some IBM user group meetings, especially those associated with FORTRAN in the early days, hearing what changes were coming and getting the user community feedback. I found them to be very helpful.

Nebeker:

What about ACM or the IEEE Computer Society?

Nieberding:

I occasionally would get information from them. I actually had presentations at a couple of the IEEE conferences. I talked once, very early on, about the transformer designs and how we used our computer programs for that. That was back in 1963, when computers were first starting to blossom. I had a lot of people in the audience that just couldn't understand how we could use computers to help design transformers.

Nebeker:

I see.

Nieberding:

To them that was something you did manually. You went out, you wired them up, you tested them out, and all that. I enjoyed that conference, and the interaction with people there. Back in '74, I had a presentation on the real time executive program that we used down at NASA. Similarly, I did one on database management. It was very interesting, too, because database management was just starting to come out about the time I gave that presentation for technical applications. It was always deemed too slow. It's fine if you're sitting down and you want to look up something in a database system, like a social security number or a payroll kind of thing. But when you're dealing in real time, again with lots of data coming in, you can't use normal database management techniques. You can't afford the time it takes to go out and sort through and search and come back with a piece of data. So we had to come up with a system such that you used database management, initially, to put your data in and cross-reference it. Relational databases are very nice. You can look up social security, for instance, and get everything associated with it, cross-referenced. We would do that before we ran the real time system, and then set up tables and data that you could sort through.

Nebeker:

The data organized for quick access.

Nieberding:

Yes, exactly that way, and with certain sorting algorithms and data compression techniques. So, I was trying to show them how we used what the DEC people came up with, a database management system called DBMS 11, and how we were able to use that for satellite command and control down at NASA.

So, those were really the three publications that I got involved with. Now, I did become a professional engineer in the State of Maryland. One of the impetuses of that is when they started talking about professional engineers, it was noted that no one from software had been able to get in as a professional engineer. So, it was suggested, or maybe I took it on my own, I don't quite remember, but I said, "Okay, let me do it." At that time, they allowed you to submit proof. You didn't have to take tests, but you could prove that in the years you've been working, you had done enough engineering type of work. So they thought it would be a good test case for me to submit all the software engineering that I had done, including the papers I had written. They accepted it, so I became I believe the first software engineer to become a professional engineer in Maryland.

Nebeker:

I see.

Nieberding:

I never had to use it. It was more for the title and the prestige that would go with that. I never got a stamp. Also, you need insurance, so that if you ever sign off as a professional engineer, they can't sue you. Never got into all that.

Nebeker:

But you made the point that software engineering is a type of engineering.

Nieberding:

Absolutely, a very important part of engineering.

'Reusing'

Nebeker:

Is there anything that I haven't asked about that you wish to make any comments on?

Nieberding:

<flashmp3>539 - nieberding - clip 2.mp3</flashmp3>

I did want to mention something about the NOAA work since Doug couldn’t be here. When they finished it up, it turned out that the systems that they had developed for NOAA to help with the activation and evaluation phase for the TIROS satellite, they were able to port those systems and use it for different applications. These systems also aided in the winning and implementation of other contracts, such as the TVA nuclear power plant monitoring and the MX missile canister test program. These were two entirely different programs from spacecraft, but again the idea of testing and evaluating a real time application where you're getting some type of real time data. The real time data might not be spacecraft telemetry data, but it could be from the TVA monitoring systems for nuclear monitoring, as well as the MX missile canisters sending some kind of sensor data.

Nebeker:

Yes.

Nieberding:

Now, we did a lot of that reuse, like I was telling you on the Jordan and Peace Shield jobs, where we came up with common software that could be used by others. But these were actual applications. In other cases it was just what the engineers learnt from the experiences they had at NASA/NOAA. They came back and then they'd see radar data and say, "Well, radar data is very similar to spacecraft telemetry data." Or hospital applications where you're monitoring patients, all the sensor data. So handling any kind of real time data, once you have experience with it, you were able to apply that in future systems.

Museum Collection, Hobbies

Nebeker:

Do you know of any objects in the collections, at the museum here, that you developed and worked on?

Nieberding:

I just took a quick tour. I saw that the TIROS satellite was mentioned, and also ATS-6, the Application Technology Satellite. That was the first of the 16 satellites that we worked on down at NASA. So it was good to see that it got a mention. That happened to be a communication satellite that they were testing out before they launched all the COMSATs and all the other communication satellites.

Nebeker:

Do you have any hobbies or other activities that you care to mention?

Nieberding:

I like walking a lot. I'm in a walking club that does 10K, which is 6.3 miles. And I enjoy movies. Now that I'm retired, I can catch up on old movies, new movies, and that. And I help out at church, and I have four grandchildren, so occasionally get called in for that.

Nebeker:

I can imagine.

Nieberding:

One thing I really enjoy, since I've lived around here all my life, is setting up lunches with guys I went to grade school with, or high school, or college, or recent neighbors, or old neighbors.

Nebeker:

Like self-organized reunions?

Nieberding:

Yes, exactly, and I love doing that. I enjoy planning those and setting them up.

Nebeker:

That's great.

Nieberding:

My wife and I enjoy driving vacations. We just recently drove out to Chicago, in September, and saw places I'd never saw before, both going and coming. And I enjoy planning almost as much as going on the trips themselves. The Internet's amazing for that.

Nebeker:

Great. Thank you very much for the interview.

Nieberding:

Oh, thank you.