Simplicity => Tranquility

Mission critical. First define your mission, then define the points of criticality where failure would be potentially or actually mission catastrophic. Outline those breakpoints and define failsafe exit strategies to escape any potentially catastrophic error in the execution of your mission. These sorts of checkpoints are second nature to the kinds of human activity and exploration such as space travel, where the margins for error, particularly in cases such as the current mission to and from the moon, are vanishingly small; and where there is an almost total reliance on computers and software to achieve the safe passage of machine and crew there and back.

Nasa and the Jet Propulsion Laboratory know this utterly: their standards of software control are second to none. They operate under conditions of multiply redundant software systems that fail safe and delegate to the next tier of machine control by default. In the days of the Apollo missions, software was small in scale and largely hard-coded, but nevertheless, there was known error and the potential for catastrophic failure; so several, independently programmed flight computers operated in a framework of co-dependant redundancy: if one failed, the next would pick up the plot and so on. This holds true today. Although the computer systems employed in space missions are many orders of magnitude more complex than those of the 1960s and '70s, and the computer languages employed are of a much higher level - and frankly more likely to evince errors - the Nasa/JPL philosophy underpinning their systems is pretty much that employed over fifty years ago in the early days of lunar exploration.

They currently have ten rules governing mission software development: any more would not be immediately memorable and therefore not useful or safe. All of these rules specify the simplest and most rigorous of code structures that can be used. Ones that eschew loose and vaguely bounded loops, and keeping to the simplest possible control flows; that and the absolute prohibition of recursive structures; no dynamic memory allocation, and so on. In short, keep things as simple and stupid as possible. Code should be readily, humanly readable and its component parts easily over-seeable. Occam's razor writ large, yet again: you know it makes sense, as much in daily life as in these much higher ventures...