Outside of software, resilience engineering is an established field using this definition and disambiguating the others. Some info on the origins going back to the 70s http://erikhollnagel.com/ideas/resilience-engineering.html. It’s only the last 5-10 years that people in software have been getting involved

> Readers beware -- this particular taxonomy of robustness vs resilience is not a pervasive or even common one. Often these terms are used completely synonymously. And often they are used with different subtleties that distinguish them.

> For example, some distinguish between the two terms in that robustness refers more to staying functional in the face of failures, where resilience refers more to the capability to work around failures (neither having anything to do in particular with whether the unknowns were unknown).

> The blog post author says that this taxonomy come straight from David woods, so there's no problem. Just keep in mind that most people don't use these terms in this particular way.

Can you go into more detail with specific examples between the two that highlight the differences? "Working around failures" and "staying functional in the face of failures" sound borderline synonymous to me, so I'm curious how that plays out in practice.

> "Working around failures" and "staying functional in the face of failures" sound borderline synonymous to me

One is going around the iceberg, the other is ensuring the Titanic can sail on with a couple of huge holes in it's hull.

If the Titanic does not hit the iceberg, it does not enter a failure mode. That doesn't sound like "working around failures" but "avoiding failure" which seems very different.