A small body of determined spirits fired by an unquenchable faith in their mission can alter the course of history. Mahatma Gandhi, social reformer and independence movement leader. 

Gordon had dumped a pile of GPS documents on my desk. There were 13 of them to be exact, and they were specifications defining the requirements for the computer programs for the GPS ground control system, called computer program configuration items, or CPCIs for short. They defined the 13 main functions for operating GPS, including space vehicle command and control, ephemeris and clock, ground antenna, monitor station, control and display, mission scheduler, and the realtime executive. There was actually a 14th CPCI, but it was classified Secret, so I would not see it until much later. Our job at that point was to get familiar with each of the primary functions for the operational control system. After that, we would begin to review the ICDs, or interface control documents, to understand how the functions would communicate with each other. For a junior engineer, it was mind numbing: thirteen specification documents and each of them hundreds of pages long. 

Work in the aerospace industry brought me into a whole new world of terms, and working on GPS was no exception. The acronyms seemed to go on without end. The OCS was the Operational Control System, the MCS was the Master Control Station, PQT meant preliminary qualification test, FQT was the formal qualification test, and so it went with GAOCP, MSOCP, PDS, CPCI, B5, C5,FCA, PCA, and a slew of other terms. Fortunately, since I ended up spending my career in GPS, most of the terms were fully reusable over many projects and never expired. I started working on the OCS in 1980 and finished with the OCS in 2020, and never had to look up any term after I first learned them. Quite efficient really!

Some terms came more slowly than others. One technical term was a reference to the flight trajectory of a satellite in orbit, called the ephemeris. Its plural was unusual to me, however, being ephemirides. And it had an unusual pronunciation. Instead of being eph – EM – er – ides, as in the Ides of March, it was pronounced eph-em-AIR-i-deez. I learned this the first time I spoke it incorrectly and was corrected, so I wrote the proper pronunciation on a small card and left it on my desk to review it each day until I said it correctly. 

In November 1980, I started my work under Gordon Small, a sharp, friendly guy from New Jersey. Gordon had assembled a team to do the independent verification and validation. The team was quite large, with eventually 21 persons supporting the IV&V in some way or another. One odd thing that I remember was that seven of the 21 team members were named John. There was John Kooker, John Haynes, John Fisher, John Berg, me, and a couple of other Johns. And not one Jack among them. Other team members included Dr. Sol Vidor, a brilliant CalTech physicist from Long Island, Alan Armstrong, Leon Palmer, and Alice Lee.

As mentioned, Dr. John Berg joined the Logicon IV&V team. I valued having John on our team as he was extremely knowledgable, intelligent and meticulous in all work he did. He stayed for about a year then moved on to the Aerospace Corporation where he became one of the top experts in the GPS control and space segments. Not all time we spent together was technical, however; John and I planned one of the annual Logicon picnics.

My job was to be the technical liaison to the GPS Joint Program Office on site at IBM Federal Systems Division in Gaithersburg, Maryland. Navstar GPS was a joint program, combining the key military branches of the Air Force, Navy, Army, and Marine Corps, and also the U.S. Department of Transportation. In January 1981 Melody and I flew to Gaithersburg to look for a house. We had spoken with our realtor, Pete Ciulio about what we were looking for, and when we arrived, Pete had about four or five houses lined up for us to look at. It was January, and Melody, a Southern Californian, was unfamiliar with the seasonal effect on deciduous trees and remarked that the trees all looked dead. They are just “dormant,” I told her, “The leaves will come back in the spring.” We found a house that was perfect for a young couple out in Poolesville, a quiet community 13-miles west of Gaithersburg. The house was a four-bedroom two story home on a quarter acre of land. When Pete first told us about the house, Melody thought he had said it was in Poodlesville, which made her concerned, but that was soon cleared up. For us, the house was pricey at $79,000. This was during the 1980’s and mortgage interest rates were 13.5%. But we managed to make it work for the next 20 months until we returned to California. 

My drive to work was pastoral, taking me past sod farms and many large stands of trees. It had one traffic signal going in to work in Gaithersburg and none coming home (a right turn), and only took 18 minutes to my office at 21 Firstfield Road. From the first trip to work, I was enthralled with this scenic drive, quite happy to be out of LA traffic. 

The IBM GPS Program Manager was Denny Welsh, with Tom Devine head of development and Jerry Durkin the GPS OCS Test Manager. Since most of my work involved independent testing, I was assigned to report to Jerry, a downeaster with a dry Maine accent and a sternness that was intimidating. With his direct manner, Jerry was able to command a large squadron of test engineers to do what was needed to thoroughly verify system requirements. Despite the formality and clear pecking order at IBM, Jerry was very accommodating to me, recognizing that I was a representative of their customer, the US Air Force at Los Angeles Air Force Base. He arranged for me to have my own office with desk, phone and bookshelves, which was unusual for a person of junior standing. I was only 29 years old at the time. 

While I had experience with IV&V, I was new to qualification testing, one of a set of tests contractors conducts when selling off systems to the government. Jerry took the time to explain how the test process worked and how I would be involved. My role would be to monitor the actions IBM was taking for testing so that I could report back to our customer, but not to be part of the test. He explained the office protocols at IBM for those working at the facility. These protocols described what type of offices and desks personnel were accorded based on their experience level. Because my role was the Los Angeles Air Force Base liaison, I had my own office, but it was large enough to accommodate a second person, once that person had been hired. It was an interior office, as offices with windows were reserved for managers. My desk was metal, not wood, as wooden desks were reserved for higher level managers. I had my own telephone, but it could not be used for long distance calls, due to their expense. Calls to the office in California required me to use an AT&T long distance phone card provided by Logicon. For each call, I would dial the toll free number using the phone’s touchpad, then enter the Logicon phone number followed by the phone card code. It did not long to memorize the AT&T telephone number and the 16-digit phone card code. 

While on site at IBM, I began to learn in detail how the GPS control system would work, and was soon awash in its myriad acronyms and abbreviations. In addition, there were the military standards. I learned that every item produced for the military had to meet a military standard. If the item was a “specification” it had to conform to a document titled, “MIL-STD-490, Specification Standards”. I was a very thorough engineer, and always ensured that I had the latest specification. One day, though, I ordered the wrong military standard from the library. I wanted MIL-STD-490, but incorrectly typed MIL-STD-1490. The document arrived, but not what I expected. Instead of “Military Standard: Specification Practices”, I received “Provision for Evaluating Quality of Coats, Men’s, Dress.” I found it more entertaining to read than the intended specification, discovering that the word “slub” is a term to describe a defect in fabric. I guess one person’s bug in software is another person’s slub in soft-wear.

IBM took their work quite seriously and professionally. Along with developing physical items, like computers, tracking stations, and communications devices, they prepared many documents. These entities were called “deliverables”, that is, documents or items that the contractor was required by contract to deliver to the customer. Every requirement, design, and test document was a deliverable and had to conform to a “DID” or Data Item Description, which directed what was to be included in the deliverable and the format to be followed. For example, DIDs dictated all documents were required to have a cover page, a table of contents, and a reference documents section. This DID ensure that all the documents looked the same in structure, ensuring consistency of content. 

A large contract like the GPS IV&V effort involved hundreds of documents to be delivered to the government for their review and eventual acceptance, or at a minimum for filing for later use. Each document was identified with a unique document number, along with due dates and specifications for its format. Producing deliverables was essential for IBM to be paid for their work. If they did not deliver the documents, they would not be paid. Occasionally I needed to review a deliverable document so I’d run down to the Data Management office to get it. Nothing was online in those days. All documents were printed and kept on shelves in the Data Management office, a huge room set aside with book shelves filled with multiple copies of all the deliverables, which I would visit and check out documents for review. It may have been expensive to maintain, but it was very well run and quite accessible. 

IBM had a large building with a cafeteria where we ate, either food we purchased or lunches we brought from home. I got to know many members of the team at IBM over lunch-hours, including regular lunch chum Art Dorsey, a PhD student in electrical engineering at the University of Maryland. His dissertation was on the GPS Kalman Filter, the brains of the GPS system. Art and I would often chat in the cafeteria about whatever came to thought. He would explain the Kalman filter to me, how it would process the GPS measurement data to generate essential states, like satellite position and time, solar wind, and monitor station states. It did not come easily to me, a former math instructor, and it was not until years later when I worked in GPS Control System maintenance and saw the Kalman filter in action that I understood the significance of what it was doing. I got a bit silly back then and would often share with Art recent jokes I had heard. He grew fond of these, calling them my “Joke du Jour”. Even in our last telephone call over 40 years later, just before Art retired in 2022, he once again asked me for my Joke du Jour. 

In April 1981, a number of us engineers watched the first Space Shuttle launch from televisions in the IBM cafeteria, a proud moment for the group, as IBM was a key player in developing the software for the Space Shuttle onboard computers. The real-time executive software for the shuttle was ported over for use to run the computers for the GPS Master Control Station. 

Also around that time, there were rumors that the Navstar GPS program was in danger of being canceled. Congress was concerned with the huge cost of funding GPS, with its multibillion dollar price tag. It had already slashed funding in 1979, reducing the constellation size from 24 satellites 18 (plus 3 spares). Fortunately, a secondary payload had been included on each of the newer GPS satellites, called the Nuclear Detonation Detection System, or NDS, run by the Air Force Technical Applications Center. The United States had signed a nuclear test ban treaty years prior, and this treaty needed to be monitored. This could only be done effectively with space-based assets. Because the GPS satellites had this payload, their importance increased, as well as the cost effectiveness of GPS satellites in the eyes of the Department of Defense. So as long as GPS kept NDS on board, the funding appeared secure. And so it was. GPS received congressional funding and was back on track. 

I opened the Logicon office at IBM Gaithersburg in February 1981 and in the fall hired Steve Weaver, a tall, bright, amiable engineer. He and I shared the duties of our work in independently verifying the testing of the OCS software and systems, including reviewing requirements, design and code documentation, attending design and code reviews, and code and qualification tests. Steve was quite a character, always offering personal insights and recommendations. One time, he told me that to dress successfully, one just needed an expensive watch and nice shoes. Everything else didn’t matter, just the watch and shoes. I made sure my shoes were shined after that, even though my watch was a nerdy Casio calculator watch. 

One day, Steve came into the office reporting that he had found some 1200-baud modems at a church bazaar, but they didn’t work. The modems were embedded inside aluminum cases, and Steve thought we could make some nice money by selling the cases for scrap. These modems were four times faster than the 300 baud dial-up acoustic modems we had been using, so I was more interested in the modem rather than the case. But there was still the problem that they didn’t work. I mentioned this to colleague Leon Palmer back in San Pedro, and he hatched a plan to fix them and then sell them into the LA technology flea markets. All we needed was to get our hands on as many as we could, ship them to Leon, and he would repair and sell them. So I asked Steve to go back to the church people and buy as many as he could. We obtained scores of these modems and shipped them back to Leon to repair and sell. I don’t know how much money we made, but for young aspiring entrepreneurs like us, it was a quick and easy success story. 

While at IBM, we got to know many engineers on a personal level. Even though Steve and I were government representatives at their facility, the engineers treated us as peers, inviting us to technical meetings and consulting with us on technical matters. For example, I remember one time attending one of my first code reviews at IBM. In reviewing the code, I caught an error in the way a logic rule was not properly being implemented. The code review team agreed, and changed the design to properly handle it. Don Haar was the one of the capable IBM software engineer who knew these modules inside and out. Although legally blind, he used technology to read all the code, and kept us on our toes. I remember him returning to work on Monday mornings in the winter telling us of his weekend exploits, which included snow skiing. 

In addition to Jerry Durkin, the test manager, I got acquainted with the project leaders and senior engineers. Dave Winfield was a brilliant engineer overseeing the design and development of the space vehicle command and status function, which handled satellite commands and processing state-of-health telemetry from the satellites. The program manager, Denny Welsh, was only seen at high level meetings with the Air Force customer. It was clear he was highly regarded as a good leader by those who worked under him. One time Mr. Welsh and I were at Dulles airport waiting for our flight west, and he was most gracious in spending a good period of time visiting with me, getting to know me and talking about my career and my experience at IBM. 

Throughout 1981, every month or so, the Air Force and IBM would hold large review meetings, bringing in engineers from all over the country. In addition to the experts from IBM Federal Systems, there were engineers from Harris Corporation in Florida, a major subcontractor building the ground tracking stations and software, government subject matter experts from Aerospace Corporation in California and experts from The Analytic Sciences Corporation (TASC) from Reading, Massachusetts. The review meetings were often held in a large auditorium which seated several hundred. Attending the system design reviews was fascinating for me. These meetings went far beyond a presentation from a contractor to their customer. They became a free exchange of ideas. Presentations were made by engineers and managers to the group, of course, but questions were asked throughout the presentations, and many changes were made as a result. Dozens of action items were written at the meetings for later response and action. We all felt that the product was getting better after each of these meetings. IBM was extremely efficient in recording these written requests for information, carefully identifying who had written the request, what was asked, and then meticulously following up to ensure that the questions were answered to the satisfaction of their author and the customer.

A key analyst for Aerospace Corporation memorable to me was Bryant Winn, who would argue vociferously with IBM engineers for his position, which included either features he felt were needed or approaches that needed to be implemented. “Vociferous” in this case meant pretty much knock down and drag out verbal fights right in the middle of technical interchange meeting. Needless to say, these interchanges were unforgettable, and it appeared that neither side would back down for days. Bryant was very good at getting his way, though, leveraging every tool he had in the government’s arsenal. 

Another engineer who actively engaged in technical discussions at technical meetings was Tom MacDonald of The Analytic Sciences Corporation. Tom was memorable for his thick Boston accent and ability to grab attention for whatever he felt was important, often telling jokes that had all of us laughing. One day, he told the crowd in the room, “People say that a one L lama is a spiritual lead-ah and a two L llama is an animal from Peru. Do you know what a three L la-mah is? It’s a really big fy-ah in Bah-ston!”

A memorable meeting was a critical design review for the Master Control Station. On June 25, 1982, once again I was in my suit and tie, pencil in hand, fully engaged in a presentation by one of the IBM engineers when I received a tap on the shoulder. I made my way out to the lobby and was told, “Your wife just called, and she is ready to go to the hospital.” Everyone knew we were expecting our first child, and that I was to be interrupted if Melody called. With this word, I was on my way, making the 18-minute drive home. Melody’s mother Dorothy had been in town waiting for the baby, but with the delay in the birth she could wait no more. Her flight was scheduled the same day that our baby had decided to arrive. “Dottie, here is the key to the Pinto. You’re going to have to drive yourself to BWI. Just please, please remember exactly where you parked the car so we can go back later and get it.” With tearful hugs, we said goodby to Dorothy, and headed for the hospital in Washington DC. Daughter Miranda was born later that day. Gordon brought us a begonia plant to celebrate, and yes, Dorothy remembered where she parked the car and we were able to retrieve it. She too was happy to be a grandmother!

IBM’s OCS contract was a “cost-plus award fee” type, also called incentive fee. This meant they were able to bill progress payments to the Air Force for the materials and hours they worked, but with little profit at that point. The profit came through an award fee that was based on their performance on contract. If the company did everything expected of them, they would receive a 100% award fee. If it was less than satisfactory, then their award fee would be reduced. IBM managers knew this, and their success in the company was affected by how well their teams did in supporting a full award fee. From my perspective, IBM management did very well to ensure the government was pleased with the progress throughout the program. 

The most appropriate simile describing my first months in Gaithersburg was that it was like a full scale blizzard. First there was a two-day OCS System preliminary design review (PDR), followed in March by a 4-day MCS Configuration PDR, MCS Data Interface Control Document PDR, Operations Date Interface Control Document PDR, then PDRs for many of the CPCIs (Selective Availability Management, Systems Log, Scenario Generation), all at the IBM Facility in Gaithersburg. In May, I was back in Los Angeles to attend reviews of the Performance Analysis Tools, Ephemeris & Clock and the Operational timeline, and later off to Melbourne, Florida to review the Ground Antenna Operational Computer Program. The last week of the month, we reviewed Network Control and SV Command/Status CPCIs. We were constantly traveling. I flew out of Dulles Airport so often, I developed my own “best practices” for travel which included taking a red-eye overnight flight from Los Angeles to Dulles and then driving to White’s Ferry to cross the Potomac in the predawn darkness, thereby avoiding traffic on the beltway around DC. Melody got used to me arriving at the house at 9 in the morning and crashing on the bed. 

Something I didn’t realize at the time, but learned years later was how expert the team of people was that we had working with on the development of the GPS control system. The Air Force person in charge of the technical program for the Operational Control System was Maj. Russ Nakamura. He seemed to be everywhere all at once, and stayed on the program for the important early years of design and development, providing the needed continuity required for working with a prime contractor. Under him were both Air Force officers and members of the Aerospace Corporation providing expertise to the government. Most active in the software engineering and development was First Lieutenant Rich Blomseth, a bright and hardworking officer from Los Angeles Air Force Base. Maj Nakamura wanted things done well, and in the proper way. One day, while we were attending a meeting in Gaithersburg, the major noticed that Blomseth did not have his tie on. “Where’s your tie, Rich?” Major Nakamura asked, a bit peeved. “It’s in my car, sir,” replied Blomseth. “Well, go get and put it on!” retorted Maj. Nakamura. “I can’t, sir,” was Blomseth’s uncomfortable response. “Why not?!” Maj. Nakamura responded, now a bit agitated. “Because my car is back in Los Angeles, sir!”

IBM was such a big company, they would to provide expensive motivational and educational pep talk movies for their employees, some even made with well known actors. One of our design review meetings opened with a short hilarious movie with Bob Newhart telling why we should buy IBM computer equipment. Meetings were held in large conference rooms with theater type seating for hundreds of people. Smoking indoors was customary then, and every day I would come home smelling like cigarette smoke. The same was true for airplane travel. Although an effort was made to locate smokers in the back rows of the aircraft, their smoke still wafted forward towards the front. “No Smoking” lights would appear during take off and landing, but otherwise we had the trace of cigarette smoke throughout the flight. I wore suits to meetings, and they often needed to be dry-cleaned to get the smoke out.

In between attending meetings, my days were filled with mundane matters, reviewing documents, preparing for meetings, writing down my comments, and preparing and sending reports back to the Logicon office. In the code reviews, we would sit down with the programmers and engineers and walk through the logic, line by line, verifying it met the requirements, design strategy, and format that had been established. Documentation of the code was very important, as I found out later. The code documentation was an essential part of software maintenance providing important background information on why the module or function had been written, what data it needed to process and what data it would generate. There were design protocols to follow so that every part of the tens of thousands of lines of code was consistently documented. The code reviews were tedious work, but usually resulted in catching errors that would be corrected. Every error caught early in the process was one less bug that would appear in the system later on. Any reports written were done by hand or with a typewriter. I spent time regularly on phone calls back to Logicon in San Pedro to keep them apprised  of the status and progress, as well. After Steve Weaver joined the office, we split up these duties, and then shared with each other what was going on. Our Air Force customer was very appreciative hearing from us, learning first hand what was happening on site with their prime contractor.

Working at IBM without a direct manager looking over my shoulder, had its perks and granted me a lot of flexibility. By the time spring came, Melody and I had spring fever. One day, the weather looked to be sunny and warm, and the cherry trees were blooming at the tidal basin in Washington DC, so I called Melody and suggested we take a long, long picnic lunch down by the Jefferson Memorial. We drove home to pick her up, then went to the Shady Grove Metro station and took the train downtown. People were out everywhere, but being Washington, everyone was in business attire, meaning suits. Even I wore my jacket and tie! But I was fascinated to see that despite the walkers dressed in suits, they still wore comfortable white sneakers, quite an odd combination, yet very practical. 

The Air Force’s team of experts largely came from Aerospace Corporation, a federally funded research and development corporation. I was fortunate to work with Jim Fogarty and Preston Prouty, two senior engineers assigned to support the Operational Control System development. Preston and Jim were hard working engineers, who put in long hours reviewing documents, asked insightful questions, chase down answers to the questions, and attended the never-ending meetings.They would attend all review meetings, read the planning documents, ask questions, and make sure that every question that had been asked was answered. They not only reviewed the work that IBM was doing in developing the OCS, but also reviewed the Logicon progress as well. As a young engineer, I was in awe of the ceaseless questions they asked the contractors at every stage of the development process. Through them I learned that if you had a job to oversee work for the government, you did it well. Alyce Jackson was one of the Aerospace engineers providing many helpful comments on Logicon’s work. The Aerospace engineers all reported to their boss, Pete Swanson, who lead this capable group of folks. It was a team I termed the “Circle A Corral”, because the Aerospace logo consisted of an A with a circle around it. 

The software at the MCS was largely written in JOVIAL 73, a computer language developed by the Air Force and issued in 1973. JOVIAL is an acronym derived from the words, “Jules’ Own Version of the International Algorithmic Language”. The language was easy to program and read, and IBM did an excellent job of documenting all of their software. Data structures used a data type called Compools, which defined the structure of everything from data storage to telemetry data. All engineers working on the program had to take courses in JOVIAL to become familiar with the language. The advantage to using an independent language like JOVIAL was that code was independently developed and tested within the Air Force system and was not subject to issues associated with commercial software such as periodic updates, or having nefarious code inserted as back doors. This approach was more expensive than using commercial software, but it also was more secure and resistant to changes. 

In the fall of 1981, I took a step I never thought possible, buying my own computer. As newlyweds, Melody and I really couldn’t afford to buy the thousand dollar Apple computer, but I wanted one really bad. I heard of Atari’s new model Atari 400 which sold for about $400, and I thought, this is it. I began to think of ways I could convince Melody to let me buy the computer. I finally came up with an novel approach. I would write a program to simulate a lunar lander and tell her that I had this program, but no computer to run it on. The initial set of instructions was really just an outline of a program modeling the motion of the lunar lander, simulating lunar gravity, the force of the thrusters on descent, and the action of the lateral thrusters to control the craft’s trajectory. I showed her the program, explaining there was no computer to run it on, and that Atari was selling their computer for only $400. Could we go down to the store and buy it? How could she say no?

My strategy worked! Soon I had a new Atari 400, complete with a membrane keyboard (no keys, just a plastic sheet with the letters and numbers stamped on it), a tape recorder for data storage, and wiring to connect it to a TV set for the display. I felt Atari was better than the Commodore computer because it had built in logic for creating moving objects on the screen, called “sprites”. Sprites could be manipulated on the display without having to draw, undraw, and redraw them, as the operating system took care of this. So all I had to do was create a lunar lander sprite, then I could control its motion with my algorithms. I wrote the program in BASIC, using special Atari functions for controlling the sprite. I devised the lunar lander to have a large, bright flame fire out of the bottom, and small flames from the side thrusters.  I gave it sound effects, even though in the vacuum of space there is no sound. They included beep-beep timing sounds and thruster firing sounds. Soon I had a working lunar lander! That was my first foray into writing my own computer programs.

Late in September of 1981, I was called to work on another project at the Logicon office in Washington, DC. They had requested my help on a project called the Advanced Indication System, a software tool used in defense intelligence work. Over the next couple of months I would go down to Rosslyn to work on this project. Although the work on AIS was interesting, the drive into DC was not, and if I chose to get further involved, I would need to obtain a much higher level security clearance, which would bind me to intelligence systems for many years. When I was asked to stay on AIS, I respectfully declined. My career was in GPS, and that is where it would remain. 

I had one unforgettable and unfortunate day during this time working in Rosslyn. On January 13, 1982 the weather was snowy, and by the time I left DC in mid-afternoon to return home, heavy snow was falling pushed by with strong winds, causing snow to accumulate on the roadways,. It was very slow going up the George Washington Parkway, as I plodded along in our Ford Pinto, listening to local radio. To my shock, I learned that a plane had just crashed into the 14th Street bridge, just three miles south of where I had been. Air Florida flight #90, had just taken off from National Airport on a flight bound for Fort Lauderdale, Florida when it failed to achieve lift, crashing into the bridge. I later learned there were 74 passengers and five crew onboard and only four passengers and one crew member survived. That was the closest I had been to a tragedy of that size. 

I finished up my work in Gaithersburg in November 1982, and we made plans to move back to California. Melody and I decided to be creative in our return home and took the Amtrak train. We departed Washington, DC, at Union Station, leaving our cat with a friend from church, and traveled in a Pullman car to Chicago. We then transferred to the Empire Builder on the overnight journey to Seattle. which I thought whould have been quite the scenic route, but was surprise when the train traveled through the midwest during the day and across the Rockies at night, so we missed seeing these majestic snowcapped peaks. We got to visit such scenic spots as Fargo and Minot, North Dakota. Sigh.… From Seattle, we took the Coast Starlight to Los Angeles Union Station, running along much of the Pacific coastline. There were three of us on the journey, Melody, me, and our 3 month old daughter, Miranda. From my count, we had seven pieces of luggage, of which six were for Miranda. 

We still had not sold our house, so had to move into an apartment at my parent’s house in Costa Mesa, California. Mortgage rates were still around 13%, so both selling and buying houses were a bit problematic. After five months our house finally sold, and we bought a house in Westminster, California, where we lived until 1988. 

Just before our move back to Logicon in San Pedro in the autumn of 1982, I received my first promotion ever, to section lead. The odd thing was, I was the last person to learn about it, because my boss, Gene Nicholson had already announced the promotion to the department earlier that day. As previously mentioned, communication was antiquated back them. I remember feeling a bit left out of the loop, and it was not until I returned to the office in San Pedro that I began to feel a regular member of the team again. 

My duties in San Pedro were as head of the GPS independent test group and manager of the Navigation Analysis Section in the Systems Engineering Department. Later in August 1983, I was promoted to assistant program manager of the GPS IV&V project. In those cases, I heard about the promotion before it was announced to the rest of the team.

From time to time, the trajectory of the GPS program was significantly affected by world events. On September 1,1983 the Soviet Union shot down a Boeing 747, Korean Airlines Flight #007, claiming that South Korea had violated airspace restrictions by flying over Russia’s highly secret Sakhalin Island. This tragedy was said to occur because the aircraft’s inertial navigation system did not maintain the true position of the aircraft, but instead allowed it to drift over time, causing the plane to fly over Sakhalin Island, a situation unknown to the pilots. President Reagan came on television decrying this incident. Within days, word came that the President had authorized Navstar GPS for use by civilians at no cost to prevent a repetition of this tragedy. [19831003 AWST Senator Urges Accel of Navstar]. This action solidified dual use for GPS at the highest level of authority. Although the president had said GPS would be available for civilian users, it would be about another 10 years before this became a practical reality, and even then, civilian users were given a degraded level of service called selective availability. 

In August of 1983, I was appointed Assistant Program Manager for the Logicon GPS IV&V effort, and worked under Dr. Sol Vidor, manager of the Systems Engineering Department. My job was to lead the independent test effort to go beyond the testing that IBM was doing to explore various scenarios and ensure the software met operational needs.

Logicon was good at providing training for its employees. While there, I took in-house courses, including Technical Writing, a Manager’s Workshop, and a Proposal Leadership Course hosted by IBM Federal Systems Division. 

For several years, I had been asking Logicon management at my annual performance review for permission to attend a workshop on software testing. Finally in February of 1985, I was able to attend the workshop Software Testing Management taught by Dr. Bill Hetzel at Sawgrass Resort in Ponte Vedra Beach, Florida. I flew to Jacksonville, Florida to participate in the five-day course. After six years experience performing independent verification and validation, I felt it was a great time to take my experience and knowledge of software testing to the next level. Sawgrass Gold Resort in Ponte Vedra Beach was home to professional golf’s Tournament Player’s Championship, although I was unaware of what this meant. Upon arriving, I soon learned, basking in the opulent surroundings of this world class resort, enjoying delicious food and the lovely landscaping. The training course was excellent, covering the methodologies, techniques and principles used in software testing in the industry, and it served as a foundation for later work I was to do over the next dozen years.

Logicon’s work on validating the development of the Operational Control System demonstrated the system was fulfilling software system requirements. IBM Federal Systems Division began to move toward their final audit of the system and its deliverables, and Logicon’s work wound down. In June 1985, the Air Force notified Logicon that further work on the IV&V contract would be canceled. We began to close out our work and write up a final report. What happened next was hardly an auspicious finish to a well conducted and performed project. The following spring on March 14, 1986 at 9:45 am, I was tasked with presenting a final briefing to GPS Joint Program Office, a half-hour period with Col. Gaylord Green, the Director of the program. As it happened, things did not go as planned. 

I did my part to prepare a briefing that well summarized our objectives, the work performed and process followed, test results, and the successes we had achieved. I listed about about a dozen accomplishments we had made that benefited the program. It was a cogent briefing, and crafted to take only 30 minutes for the presentation. At thirty three years old, I was new at briefing a customer and wanted to make a good impression. I entered the Los Angeles Air Force Base campus on time, passing through security, and made way over to Col. Greene’s office. I was ushered into his office, but there was already a conversation going with a 2nd lieutenant I didn’t know. So I sat and patiently waited my turn. I had been given a half hour to meet with him, but quickly learned that I would not get receive this amount of time, as he and the lieutenant were in an active discussion about the junior officer’s upcoming leave. Minutes dragged on as they discussed the upcoming vacation, and I soon realized that I would not have time to go through all the slides, but would have to trim out much of the material. Finally they wrapped up, and Col. Green turned to me and asked what I wanted. I explained I was there to give him an outbrief on the five years of work we had done on the GPS IV&V effort. I started through the briefing, but it was clear that this topic was not high on his list of priorities. After all, who wants to hear about a program that had been canceled? After several minutes, he interrupted me, thanked me for coming, and said he had to leave to take care of other business. I sighed, thanked him, and packed up my things and left. 

This was my first but not my last interaction with Gaylord Green, a significant mover and shaker in the field of GPS. Years later, Brad Parkinson would praise Gaylord for his work on GPS, identifying him as the one who selected the original GPS orbits.

When I closed out the GPS IV&V work, I felt good about what we had done, that we had made a marked contribution to the success of the program. Nevertheless, years later, I learned that we had not done all that we could have done. There was more. We did the best we could with the knowledge and expertise we have, but it was based on incomplete knowledge. We knew about requirements and testing, but we did not know about real-world operations, and so in retrospect now, I feel there was more we could have done. I did not learn this until much later when I became involved in GPS operations and maintenance, and saw what the satellite operators and GPS users had to deal with.