It IS rocket science: What space-flight training taught me about IT

Although tech writing has been my full-time gig for the last 17 years, I have also spent the last two years training to go into space. (I am not a NASA astronaut, but am training for a NASA-supported commercial mission.)

posey
Brien Posey

When my friends and family members found out that I had been accepted as a commercial scientist-astronaut candidate and was actively training to go to space, one of their most common reactions was to tell me that being an astronaut was going to be a lot different than working in IT. I’ll concede that I can’t seem to recall ever having an IT job that required me to use an anti-G straining maneuver, or that required me to pull a plane out of a spin while I was falling toward the Pacific Ocean. Even so, space training and IT have a lot more in common than you might think. For one thing, both involve taking certification exams and memorizing a lot of complex technical material. However, the similarities do not end there.

Details matter, in space and in IT

One of the big lessons that has been repeatedly drilled into my head during various space training exercises is that seemingly insignificant details matter. In a recent class for example, there were some test questions that required me to calculate a rocket engine’s exhaust velocity. The equation requires you to know the engine’s specific impulse and a gravitational constant. The gravitational constant is normally 9.8 m/s2, but on this particular exam the constant had been expressed as 9.81 m/s2. It was a tiny change, but failing to pay attention to that one small detail would have resulted in an incorrect answer.

The same basic lesson also applies to the world of IT. For example, a performance monitor counter might be reading a slightly elevated value. Although it’s possible that the cause is completely benign, it is also possible that the elevated counter can be attributed to a worsening condition that needs administrative attention. The lesson here isn’t just that seemingly insignificant details often matter a great deal, but also that it is important to be observant. In fact, being observant is very heavily stressed during space training.

During one of the classes that I had to take last year, the instructor showed the class a PowerPoint slide containing numerous squares, and told me to determine how many squares were on the slide. Coming up with an answer wasn’t simply a matter of counting, because some of the squares were arranged in such a way as to form multiple larger squares. After a brief period of time, the instructor cleared the slide and told me that time was up, and asked for my answer. I shamefully admitted that I had no idea how many squares were on the slide. To my surprise, the instructor told me that he didn’t know how many squares were on the slide either, and that the count didn’t matter because “how many squares are there” wasn’t the real question. The real question was how much time was I given to count squares. The exercise was designed to test my ability to keep track of time when I didn’t think that it mattered.

In another lesson, the instructor briefly paused on a slide containing a picture of an animal. He said that we didn’t need to cover that slide, and then skipped ahead a few slides and resumed the lesson. About 20 minutes later, the instructor asked the class if we remembered the slides that had been skipped. He then asked questions like what kind of animal was on the slide, did the animal have any physical defects, and how many slides did he skip. All of those questions were designed to help the class learn to be more observant.

In the world of IT, being observant matters – a lot. Remember Delta Airlines global computer outage? That outage was caused by a power failure in Atlanta. It was later determined that approximately 300 servers had not been connected to a backup power supply. Had the installers been more observant, a worldwide outage might have been prevented.

Decisions have consequences

space-training-1Another big lesson that is stressed during space training is that decisions have consequences. In fact, this was a lesson that was taught on Day 1. My first ever space training exercise was underwater egress training. For this exercise, I was strapped into the pilot’s seat of a simulator, and the entire simulator was plunged into a tank of water. As soon as the simulator hits the surface, water starts pouring in, and the simulator tumbles violently. I was typically left upside down under water, and strapped to my seat. My job was to get the door open, get my five-point harness disconnected, and swim to safety. You can see me in the figure above (I’m the one in the orange flight suit), getting ready for my first run in the simulator.

The exercise was performed over and over again. I was blindfolded for some of the simulator runs. During others, a door was jammed shut, requiring me to find another door. Other simulator runs added wind, rain, and simulated lightning.

As I said, decisions have consequences. One of the key decisions in that training exercise was when to take a breath. Take a breath too soon, and you use up some of your air before you are even in the water. Wait too late to take a breath, and you might not have enough air to last you until you reach the surface.

Another decision is whether to take your seatbelt off first, or open the door first. Incidentally, it is usually better to open the door first, because if you take your seatbelt off first, then your body can drift into a different position, making it much more difficult to find the door latch in the dark.

Although IT decisions aren’t usually a matter of life and death, they can still have serious consequences. For example, suppose that a vendor releases a software patch that addresses a serious security vulnerability. Do you install the patch immediately in the interest of avoiding security problems, or do you spend some time testing the patch? Either decision can hold serious consequences. This isn’t even an isolated example. IT pros must routinely make decisions in which an incorrect choice could hold dire consequences.

nasaflight3

Communication: The key to success

One more lesson learned from spaceflight training is the importance of good communications. This is especially true in high pressure situations in which team members may get in one another’s way.

The particular space mission that I am training for will be suborbital rather than orbital. This means that I will only get a few minutes in space. Because of this, there will be a lot of pressure to complete the assigned tasks quickly, efficiently, and accurately.

For various reasons, there are multiple vehicles being considered for the mission. The preferred vehicle holds two people – a pilot and a scientist. The other vehicle that is being considered holds eight people – two pilots, and six passengers – potentially a mixture of scientists and space tourists.

During one of my lessons, I was advised on potential disruptions that may impact my ability to perform my designated tasks. There will likely be people floating around the cabin for example, possibly bumping into me and into my experiment.

To stress the difficulty of performing a scientific experiment in a cabin filled with other people, an exercise was developed in which six people are confined to an area that is the same size as the spacecraft interior. Each of the six people is given a task to do, and the task must be completed within a few short minutes. What the participants are not told ahead of time is that each person’s task is designed to interfere with someone else’s task. Needless to say, chaos quickly becomes the order of the day.

Avoid crashes in space or in the office

One person’s experiment involves putting batteries into an electronic device and documenting on paper the pattern of sounds that the device produces. However, another person’s experiment causes an air horn to be sounded every fifteen seconds. Being in an enclosed space, the air horn is loud enough that it drowns out the electronic beeps, making it nearly impossible to record the sound pattern. Each of the other participants were assigned similarly disruptive tasks.

The lesson was that the “flight’ becomes much less chaotic if the participants discuss their objectives with one another ahead of time. This gives each person time to think about how other people’s activities could be disruptive to their own, and a chance to come up with a way of mitigating the disruption.

Have a flight plan

As strange as it may sound, this particular exercise immediately reminded me of a particular disaster recovery situation that I had worked through at one of the places where I used to work. In that particular incident, there was no meaningful communications between IT team members and we all kept getting in each other’s way. For example, I mounted a backup tape so that I could begin the restoration. A co-worker decided to do the same thing, but he couldn’t find the backup tape because I already had it. Since he couldn’t find the required tape, he retrieved the tape from a day earlier. Without looking at which tape was already in the tape drive, my co-worker ejected the correct tape, and inserted the older backup tape. Needless to say, this led to some confusion.

Although IT and aerospace may seem to be completely unrelated fields, there is a surprising amount of similarity between the two. If you are curious to know more about my spaceflight training, you can visit my Web site.

Photo credit: NASA

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top