Can an attentive manager, engineer, or communicator spot this? How important is your budget and schedule? If they are not important, then don’t worry about it.
Otherwise, take steps to make certain that whatever you are saying is really getting through, to the tune of: ‘‘I can look into your eyes and see the color of your socks!’’
(And I realize, to my horror, that there is nothing there.) The assumption that all in the conference room are fully involved with what an individual is saying can be very costly to a project.
HOW PEOPLE THINK, PAY ATTENTION, AND REMEMBER 121
I have always read philosophy, so when I entered the Army I was surprised by what I saw. I began to infer that people were not only not paying attention, but they didn’t even read what was in front of their faces, with costly consequences. Some events may be funny now; they were tragic then.
One of the earliest examples was an incident at Ft. Knox, Kentucky, while I was going through advanced armored training. I entered the Army as an enlisted soldier based on two romantic notions: One, that I should learn from the bottom up, by learning everything before getting a commission. And two, that I should take Napo- leon’s saying, ‘‘In every soldier’s knapsack is a field-marshal’s baton’’ to heart.
After basic infantry, I wanted to learn all about tanks, how to drive them, main- tain them, and how to shoot the weapons on them. Now, on the bulkhead of the M-48A2 Medium Tank (official designation: ‘‘90mm Gun, Tank M-48A2’’), right in front of the driver’s eyes and directly under the driver’s periscope, there was a stenciled message. The message was painted in bold white capital letters about 2 inches tall and said:
DRIVER! DO NOT LEAVE YOUR SEAT WHILE ENGINE IS RUNNING!
We had received instructions on this over and over again.
The reason for relating this story is to give an example of how people think, remember, act, and makea prioriora posterioridecisions. This lesson to me per- sonally was but the beginning of many incidents I observed in the Army that often had tragic results. Sadly, this type of decision happens as often in engineering, science, and all walks of life as it happened on that day in 1959.
We were getting ready for an inspection of our M-48A2 medium tanks after we had spent two weeks in the field on the firing range at Ft. Knox, Kentucky. We had been qualifying on the 90mm main gun. We were now back at the regimental motor pool, taking turns at the wash rack. I had finished most of my work and was hosing down my tank, washing off the mud with a hose about the size of a normal fire hose.
Also on the wash rack were several other tanks being cleaned as mine was. The one next to mine had the engine idling, and the driver was somewhere inside. I didn’t take notice, until suddenly he stuck his head out of the tank commander’s hatch and pulled himself out. He climbed down the turret and jumped off the fender skirt to get something from his toolbox. The big Continental V-16, with 750 HP, was idling, and I was about to holler over the noise that he should turn the engine off, when the transmission slipped into first gear! When this happened, it started to move forward.
Since he had it backed into the washing slot, there was no tank directly in its path to stop it as it moved forward. The path was clear to the drainage ditch, then on to a four lane highway; beyond that there was a 12-foot chain-link fence. Behind this chain-link fence was the parking lot of the 1st Training Regiment Armor, the U.S. Army Training Center Armor (USATCA), filled with the cars and pickup trucks of the cadre officers and non commissioned officers of the regiment.
Well, the 50 ton M-48A2 tank in first gear has so much torque that it travels on 1st gear at about 15 mph without any pressure on the accelerator. There is no way anyone would risk life and limb trying to get on board when it is moving. So it
simply moved, or lumbered, across the road. Fortunately, the traffic was light because it was about 0930 hours (back then, reveille was at 0530, so everybody was at work). The traffic halted, and the tank moved across the highway. It moved over the chain-link fence like it was nothing, and then started across a row of cars and pickups. All of the troops and the standers-by were amazed, and we ran behind it. It was headed for a company mess hall. In those days we had company mess halls and the food was absolutely fantastic because all the company mess sergeants competed for best mess hall in the regiment; we ate like kings at Ft. Knox.
Thank God there was one of those large tractor-trailer trucks delivering milk to the ‘‘chow hall’’; it was a Foremost milk truck. The guys on Kitchen Police (KP) got all excited seeing this big piece of steel coming their way; they spread the alarm and cleared the mess hall. The tank must have very casually demolished about 15 to 20 cars before it hit the trailer of the truck. The power of this V-16 Continental was so great that it simply pushed the trailer over on its side. It arched up, almost mak- ing it over the top, when it finally stopped. There was not enough engine rpm at idle in first gear to climb over the trailer, so the engine simply died.
Obviously, the reason for never leaving the driver’s seat before turning off the engine was that it was unsafe. It had a three-speed hydramatic transmission, and the ‘‘Neutral Park’’ position was located directly up at 12 o’clock, with 1st gear at 1 o’clock, 2nd gear at 2 o’clock, and Reverse gear at 6 o’clock. A bad design, to be sure, because the vibration from the engine had a tendency to shake the shifter lever loose and slip it into 1st gear.
For this reason, we were given hours and hours of safety lectures on every aspect of the tank, but above all, we were instructed never to leave the driver’s seat while the engine was running! This was literally ‘‘hammered into our brains.’’ So with all this training, with all these lectures, with all the inspections and tests and pop quizzes, why did this driver fail to remember? The answer, as Arthur Schopenhauer so well explains, is that as we human beings process information and decide, we often makea prioridecisions. These decisions are almost always wrong. I was a 20-year-old kid with two years of college and lots of philosophy reading under my belt. These phenomena simultaneously fascinated as well as dismayed me. I became a witness to terribly tragic incidents, during both peace and war. (Even I, who always tried to be very circumspect and aware of what could happen, would make a decision, which but for the grace of God, would have cost me life and limb.) For this reason, I am very careful during systems requirements, design and implementation to be absolutely focused on the members of the design team. To ensure that as we discuss each segment, subsegment, software data set, module, and routine they are clearly understood by everyone sitting around the table, and that they all are carefully documented. Then, during implementation, I can check with reasonable assurance that every programmer is doing what we agreed to do as a team. I can also reasonably predict when each task will be completed. With all this caution, I’m still sometimes caught off guard, but at least I can correct the problem.
Looping back to the story with the tank, allow me to draw an analogy to space- craft control systems. Think of it as a software compare, an ‘‘equal to’’ instruction,
HOW PEOPLE THINK, PAY ATTENTION, AND REMEMBER 123
in the mind of the tank driver as having caused the destruction of about 20 cars. An average car at the time cost $1,500 (we drove mostly Chevrolets and Fords), but those dollars were silver dollars, which today cost $10 a piece, and add inflation on top of that. So at $20,000 per car, you are talking about $400,000 for this soft- ware error. At $200,000 per engineering work year (burdened) you are talking about a big loss in time and money. To recover in software from that much loss, and still retain the schedule, you have to triple that sum in money and time. If you have blown $400,000, and you have to catch up while the rest of the team is working (this includes the design upgrades in the documentation set and test plan), it will take the $400,000 + $400,000 to come up to where you were supposed to have been on the schedule, plus an additional $400,000 to come abreast of where the rest of the project is on the schedule. Now this seemingly small and isolated mis- take costs $1.2 million. That should answer the question: Why does NASA and DOD software cost so much?
10 The Development Process Methodology
If funding is tight and a conservative development approach is required, metho- dology will play an important role. Development methodology involves the selec- tion of a number of techniques and procedures to be used in the implementation of a system. In my world of low-cost implementation, the process of selecting the cor- rect methodology is an exciting, creative, intuitive process in itself. In terms of Kantian concepts, a methodology is the selection of the appropriate organization, communication, development, and control functions from one’s wells of experi- ence, and the application of them to the project to be developed. There are standard approaches for development when the schedule and budget are adequate for the job.
Then there are the additional factors of experience. A manager-architect with a high level of experience in the technologies involved (and in communication) may not have an adequate level of experience in organizations; he will not be able to select an appropriate organization necessary to keep the development cost down.
There is good news here, and bad news. Like everything else, process and meth- odology can be learned from books, but that’s the toughest way. I did it initially from IBM and Army instructors, and not very long after that from some outstanding experts who had written indispensable books that I devoured over the years. While I was still working as the assistant architect for the Allied Command Europe, Com- mand Control and Information System, at Supreme Headquarters Allied Powers Europe (SHAPE) in Belgium, I ran across a wonderful book titledStandardized Development of Computer Software.1 Volume I became one of my basic manuals in software development. I asked the author to update the books, but he never did. Everyone interested in software development must read his two volumes.
They cover many aspects, including production.
My guide and mentor during my three years at SHAPE was a fabulous systems engineer and technical thinker, Colonel Joe Bullers. He was a chemical engineer by education and a USAF B-47 pilot by profession. He had been Gen. Curtis LeMay’s systems architect for the command and control system of the Strategic Air Command
The Cognitive Dynamics of Computer Science: Cost-Effective Large Scale Software Development, by Szabolcs Michael de Gyurky
Copyright#2006 by John Wiley & Sons, Inc.
1Robert C. Tausworthe,Standardized Development of Computer Software, Part 1: Methods, Part 2:
Standards, Prentice Hall, 1977
125
Bomber Fleet. He was handpicked for SHAPE, and he handpicked me. He was an innovative and creative thinker, and we formed a great team, the two of us. Besides being the only one who could read his handwriting, I was able to elaborate in writing and graphics the ideas and concepts he would mumble in fragmented bursts.
He was a good teacher. When our tours were over, and we retired from the Service (he with 30 years, me with 20), we were replaced by a high-powered academic team of 32 members.
Little did I anticipate that one day soon I would have some of these great thin- kers working for me. Why would some of these outstanding people, whose books I had read, come to work for me? Since I had methodology, I would become friends to many of my colleagues here at this wonderful place called Jet Propulsion Labora- tory. My methodology is actually an amalgamation of military engineering methods, IBM systems engineering instruction, much reading and practicing, and, of course, philosophy.