Perfect is the Enemy of Good

I learned to program at Purdue University when the term "computer program" meant something that was fed into a machine bigger than your house using a deck of cards that were punched by something that looked like a fabric loom. I kept up with newer computers until, in 1987, I wrote a navigation program for our Air Force Boeing 747s. That's when I learned that perfect is the enemy of good.

On my 30th birthday I was an Air Force captain living 5 miles from where I grew up, living the good life on the island of Oahu. Wait, it gets better. A year prior to that all of the more qualified pilots in the wing jumped ship for the airlines, the next layer of pilots somehow got disqualified with drunk driving charges, promotion pass overs, or various acts of willful noncompliance in the cockpit. (That is a kind way of saying, "letting non-pilots fly the expensive airplane.") So I, a snot-nosed kid of 28, was elevated to the chief of standardization and evaluation for the entire 15th Air Base Wing. Top dog among several squadrons filled with pilots who looked (and acted) twice my age. Could it get any better? Yes it could and it did. The Air Force decided I needed to fly a Boeing 747 and sent me to United Airlines to learn to fly it. A month later I had my ratings and two months after that I passed all my qualification checks and was cleared to fly the beast. But that would take a little more time . . .

“What’s a newly qualified pilot got to do to fly around here?” I asked Lieutenant Colonel Alton Gee, the squadron scheduler, a navigator, and the one man in the squadron who could fill in my empty dance card.

“Funny you should ask,” Alton said. “Follow me.”

Alton got up and led me out of his office into the next room, the door of which was marked “Nav Planning.” The room had a single desk atop which stood a North Star Horizon computer, a huge machine with a green-on-black screen capable of 80 lines of text, and two 5-1/4 inch floppy disk drives. Alton sat at the desk, flipped on the power switch and the screen blinked on with a single message: “Wait.”

Alton talked as he brought the squadron’s navigation program to life, which appeared to be written in BASIC, a programming language I had only seen on my handheld calculator. The program asked single-line questions and Alton typed in the answers. “We are flying a mission to London next week,” he said while fumbling with an en route chart, “might as well get something done while showing you the ropes.” After about thirty minutes of this, the screen blanked again and said, “Go get a cup of coffee; this is going to take a while . . .”

“You drink coffee, James-you-el?” I nodded and Alton led me to the coffee bar. I knew that being awarded a pet name from Alton elevated me to a new level of esteem in the squadron. But it still left me in a fog as to why I was getting the navigator indoctrination.

“Old Frederick Fitz was a navigator of yore who was as useless as tits on a bull, but he knew computers,” Alton said over his paper cup of Folgers. “Fitzee wrote that program and convinced the squadron commander to get us the computer. It used to take us two hours to do a flight plan, now we can do one in about an hour. Pretty good, don’t you think? Old Fitz is gone but his legacy lives on in that machine.”

About half an hour later there was a flight plan hanging down from the dot matrix printer on five pages of perforated paper. Alton ripped the sheet with gusto and announced, “Here it is, our flight plan done at the speed of light.” He scanned the output happily until about halfway down the second page, “Dammit, I missed a point.” He checked the output versus the en route chart. “Now I got to start over.”

I was looking for a graceful exit point. Looking at this computer was worth about five minutes of my interest, getting an understanding of how the navigators did their flight planning was worth the hour, but now we were moving into the waste of effort category. “Not that you need to stick around for all that,” Alton said, as if reading my mind. “But you get the idea of why we need you to fix this.”

“What?” Alton looked at me with puzzlement at first, sympathy second, and finally amusement. “Didn’t you know we hired you because we heard you know all about this bits and bytes stuff?”

“No, but . . .”

“We got a copy of the program you wrote in Hawaii,” Alton said. “We want one of those for our airplane.” I stood there, motionless.

“Come on, James-you-el,” Alton said while putting an arm around me and leading me out of the office, “you don’t think we hired you because you are a good pilot? Hell, this man’s Air Force is filled with good pilots. Now, find me a good programmer who can fly, well now you got something.”

I spent a day or two sulking but that passed. Bruised ego aside, it seemed that if programming skills got me into the squadron, so be it. I had been looking for an excuse to learn the Pascal programming language and it would seem I had ample time. The Pascal language had nothing to do with mathematician Blaise Pascal, other than an admiration for efficiency and strict procedures. I bought the Turbo Pascal compiler for thirty dollars and went to work.

The program I wrote in Hawaii had an interface just as clunky as the Fitz version: it asked the user a series of questions before doing the actual work. One advantage my program had over Old Fitz’s was mine saved the information so the navigator didn’t have to start over after every attempt. It also ran faster only because the code was written with subroutines; it was compact by comparison. I didn’t know BASIC well enough to fix the Fitz program, so I started over with Pascal and emulated a spreadsheet model, something like the wildly successful Lotus 123.

Getting the spreadsheet onto a MS-DOS screen, the best thing we had, was a huge chore but with the help of "Byte Magazine" I learned to write machine code that addressed each pixel of the screen individually. The program itself had a few bugs and was prone to making mistakes. And there was that %$#@! database.

At that point the squadron had a grand total of two IBM PCs. The first went to the squadron commander's secretary and the second to the mission planning room where it remained under the watchful eye of Lieutenant Colonel Alton Gee.

"Hey you kids stay away from that," he would say to any pilot brave enough to venture near the ON / OFF switch. "That ain't no toy."

We pilots soon figured out the machine was reserved for my exclusive use until I got the navigator's mission planning program up and running.

This sure is going to be nice, Eduel," he would say every day about noon. "I reckon' we'll be churning out flight plans in mere minutes!"

"Yup," I would say.

"Any day now," he would say. Then he would leave me alone with my code. About 4 p.m. or so he would drop by for a demo. "Eduel, that's pretty slick," he would say. "Except," he would add with the latest glitch. After about two months the program was running with just one major problem. It got lost when crossing the equator or anytime it had to change from East to West or West to East longitude. "Not too shabby, Eduel. Keep at it, you'll get it."

It was driving me crazy and I just didn't know how to proceed. When stumped by a problem, I thought, do something else. The program had a database of every airport in the world large enough to handle a Boeing 747 and every navigation aid we could conceivably need. Of course these days all of that stuff is computerized. In 1983? Not so much. I got to work inputting data. It would take me months.

After a week I noticed Alton would spend a few moments looking over my shoulder as I punched away at the data. With all the navigation charts and airport directories at my side it was obvious what I was doing. "Watcha doin?" he would say.

"Database," I would say. And he would move on.

"You know we got plenty of trained monkeys around here," he finally said. "With all the time our navigators are spending doing flight plans the old fashioned way, they could be doing all that data entry for you."

"I don't mind," I said.

"How's the equator problem coming along?" he asked.

"I'll get to it," I said.

The squadron had to fly me now and then, just to keep me current. But everyone knew my priority was in front of that IBM PC and my computer code. We were flying one of those very long missions with two crews on board. We spent half our time in the cockpit flying, the other half in the upper rest talking, playing cards, or sleeping. After several hours in the seat I strolled back to see Alton Gee at the end of one of his stories with an audience paying full attention. I waited for the punch line, the laughter, and the smug look on Alton's face. That was my cue it was okay to find a seat and join in.

"James-uel here is an engineer," he said to one of the passengers who had wandered into our territory. "He has a real-live Purdue education. In fact, he thinks in ones and zeroes."

The passenger had a blank look on her face.

"That's the language computers think in," I explained. She smiled, excused herself, and fled.

"You have a real way with women, Eduel." The crowd laughed. "Truth is," he continued while addressing the rest of the crew dogs in attendance, "Eduel is a mighty fine engineer. He just doesn't know what matters and what doesn't."

I stared at him, waiting for the punch line, which never came. "What do you mean?" I asked.

"You ever heard of Vilfredo Pareto?" he asked.

"Yeah," I said. "He was the Italian economist who came up with the 80/20 rule. It had something to do with 80 percent of any country's wealth is held by 20 percent of its people and the remaining 20 percent of the wealth is held by 80 percent of the people. I'm not sure what it has to do with engineering."

"Truth be known," he said, "I didn't know it had anything to do with economics. I read a book about it recently. The point was that we spend 80 percent of our time working on stuff that is only 20 percent important. That leaves us only with 20 percent of our time left over to concentrate on the 80 percent of the stuff that really matters."

I sat and thought. It was true, I realized. Another Alton Gee truisim for my notebook, nothing more.

"So how much longer is the navigation program going to take?" he asked.

"Hard to say," I said.

"Well let's see," he said. "You started five months ago. You had the first prototype going pretty quick, maybe in the first month. Then you started futzing around with the database and that's where you've been for the last four months. Four months of five. What's that come to, percentage-wise, Eduel?"

My mind first raced to accomplish the math. But as soon as the '80 percent' thought came to me his point was made. I gave him an embarrassed grin, admission enough, I suppose.

With the "trained monkeys" handling the database I turned to the navigation engine, which I managed to crank out with just another night's work. Then I turned to the interface, trying to get the time from each key press to the screen in fewer and fewer milliseconds. The program wasn't fast enough.

"Now what?" Alton asked.

"The numbers to pop up on the screen as fast as you can type," I said. "I need to rewrite the input/output engine."

"It looks fine to me," he said.

"It doesn't have to be perfect," he said.

"Yes it does," I said.

"You know we're still flying missions on old Fitzee's program," he said. "What you have is better than what we have been using while you've been futzing around with this or that."

"Patience," I said. "I want it perfect."

"Perfect is the enemy of good," he said.

I sat and thought. Alton shrugged his shoulders and left the room. My eighty percent effort, it would seem, was having less than a twenty percent impact. He was right.

I copied the program from my disk onto the navigator's computer. I walked into Alton's office. "You are right. The program is operational."

That chore done, the squadron started flying me on a regular basis. I started to think of myself as a pilot again; albeit a more humble pilot.

There is a lot of wisdom in the Peter Principle, including this "real life" case study of "perfect is the enemy of good." (The names have been changed.)

Peters, Laurence J., Hull, Raymond, The Peter Principle: Why Things Always Go Wrong, William Morrow & Company, Inc., New York, 1969.