From "REALLY REMOTE Debugging: A Conversation with Glenn Reeves" (2010) [0]: We did see the problem before landing, but could not get it to repeat when we trie

From "REALLY REMOTE Debugging: A Conversation with Glenn Reeves" (2010) [0]: We did see the problem before landing, but could not get it to repeat when we tried to track it down. It was not forgotten nor was it deemed unimportant. Yes, we were concentrating heavily on the entry and landing software. Yes, we considered this problem lower priority. Yes, we would have liked to have everything perfect before landing. However, I didn't see any problem, other than that we ran out of time to get the lower priority issues resolved. We did have one other thing on our side -- we knew how robust our system was because that is the way we designed it. We knew that if this problem occurred, we would reset. We built in mechanisms to recover the current activity so that there would be no interruptions in the science data (although this wasn't used until later in the landed mission). We built in the ability (and tested it) to go through multiple resets while we were going through the Martian atmosphere. We designed the software to recover from radiation induced errors in the memory or the processor. The spacecraft would have even done a 60-day mission on its own, including deploying the rover, if the radio receiver had broken when we landed. There were a large number of safeguards in the system to ensure robust, continued operation in the event of a failure of this type. These safeguards allowed us to designate problems of this nature as lower priority. We had our priorities right. [0] http://www.drdobbs.com/architecture-and-design/really-remote-debugging-a-conversation-w/228700403 http://www.drdobbs.com/architecture-and-design/really-remote...