The act of setting up multiple "defensive mechanisms" to guard against something undesirable from occurring (whether a software defect from propagating through a system, a ship from running aground, an intruder from breaking into a safe). Based on the principle that for the undesirable thing to happen, ''n'' systems would have to fail (where ''n>1'') rather than a single failure occurring. Assuming that the systems have independent failure mechanisms (one system's failure doesn't increase the likelihood of another system failing), this can dramatically reduce the probability of a catastrophic failure occurring. (Of course, independence of failure mechanisms isn't always easy to get - CascadeFailure''''''s, where the failure of one system causes another system to be stressed and fail, which causes the ''next'' system to undergo stress and fail, are far too common.)

In some engineering disciplines, DefenseInDepth is considered GoodPractice. In others (including some SoftwareEngineering methodologies), it's considered redundancy to be eliminated (as unnecessary and potentially expensive baggage). Given that DefenseInDepth often incurs extra cost for no extra functionality, in many endeavors there is pressure to reduce or eliminate redundant safeguards.

Of course, even proper DefenseInDepth can fail. The wreck of the ExxonValdez is a good case study of ''many'' things going wrong, leading to the catastrophic oil spill. While the captain (Joseph Hazelwood) was certainly drinking on duty (and his absence from the bridge due to being slightly intoxicated was one of many factors), ''lots'' of things went wrong that ultimately led to the the Valdez running aground. (This does not, of course, exclude Hazelwood for his dereliction of duty in any way. There is a popular misconception, BTW, that a drunken Captain Hazelwood personally steered the ship into the rocks; not true. He was in his cabin; and the third mate (I believe) was in the wheelhouse when the accident occurred.)

----
How about SecurityInDepth, which also scales for software projects and the manning of them.