resilience

name	resilience
description	Antifragility - systems that gain from disorder, via negativa, skin in the game

Nassim Nicholas Taleb - Antifragility

Apply Taleb's principles from the Incerto series (Antifragile, Black Swan, Skin in the Game) to build systems that gain from disorder.

Core Philosophy

The Fragility Triad

FRAGILE          ROBUST           ANTIFRAGILE
────────         ──────           ───────────
Harmed by        Unaffected by    Gains from
volatility       volatility       volatility

Glass            Rock             Muscle
Porcelain        Plastic          Immune system
Optimization     Redundancy       Optionality

Wants calm       Tolerates chaos  Needs chaos

Taleb's insight: Don't aim for robust (merely survives). Aim for antifragile (improves from stressors).

Via Negativa

What you remove matters more than what you add.

ADDITIVE THINKING (fragile):
"What feature should we add?"
"What tool will fix this?"
"What process should we create?"

VIA NEGATIVA (antifragile):
"What should we remove?"
"What's causing the problem?"
"What process is in the way?"

Application: Before adding, subtract. The system that needs nothing added is better than the system that has everything.

Skin in the Game

Decision-makers must bear consequences of their decisions.

NO SKIN IN GAME (fragile):          SKIN IN GAME (antifragile):
─────────────────────────           ─────────────────────────
Architect doesn't use system        Architect on-call for system
Consultant leaves after advice      Consultant has equity stake
PM promises features to sales       PM owns customer outcomes

Rule: Never trust advice from someone who doesn't bear the downside.

Prescriptive Rules

Prefer Optionality Over Optimization

OPTIMIZATION (fragile):
├── Maximizes for known conditions
├── Brittle when conditions change
├── No room for error
└── Example: JIT inventory

OPTIONALITY (antifragile):
├── Preserves ability to change
├── Benefits from new conditions
├── Room to maneuver
└── Example: Cash reserves + opportunities

Code application:

// OPTIMIZED (fragile): Locked into specific provider
import { sendEmail } from 'specific-email-provider-sdk';

// OPTIONAL (antifragile): Can switch providers
interface EmailSender { send(email: Email): Promise<void> }
// Implementation chosen at runtime, can change without code change

Barbell Strategy

Combine extreme safety with extreme risk. Avoid the middle.

BAD: Medium risk everywhere (fragile middle)
     ├── Some tests (not enough to catch bugs)
     ├── Some redundancy (not enough to survive failure)
     └── Some innovation (not enough to gain from change)

GOOD: Barbell (antifragile)
     ├── SAFE END: Rock-solid core (90%)
     │   ├── Exhaustive tests for critical paths
     │   ├── Multiple redundancy for key systems
     │   └── Proven, boring technology
     │
     └── RISK END: Experimental edge (10%)
         ├── New technologies in isolated experiments
         ├── Aggressive optimization attempts
         └── High-risk, high-reward features

Small Is Beautiful (Limit Downside)

Large systems have large failures. Small systems fail small.

FRAGILE:
├── Monolith: One bug can crash everything
├── Big batch: One bad record corrupts entire run
├── Giant PR: Impossible to review, impossible to revert

ANTIFRAGILE:
├── Services: Failure isolated
├── Small batch: Bad record affects only that batch
├── Small PR: Easy to review, easy to revert

Taleb's rule: If the downside is unbounded, you will eventually be destroyed.

Redundancy Is Not Waste

Efficiency removes slack. Slack is what saves you.

"EFFICIENT" (fragile):           REDUNDANT (antifragile):
───────────────────             ────────────────────────
One database                    Primary + replica + backup
Minimal staff                   Cross-trained team
Zero inventory                  Safety stock
100% utilization                80% utilization + slack

Key insight: Redundancy looks wasteful until you need it. Then it's priceless.

Code Application

Build Antifragile Systems

Antifragile characteristics:
  - Fails small, not big (circuit breakers, bulkheads)
  - Gets stronger from stress (chaos engineering)
  - Has optionality (feature flags, A/B tests)
  - Redundancy at critical points (replicas, retries)
  - Benefits from variance (load balancing, multipath)

Via Negativa in Code

// BEFORE: Adding complexity
function processOrder(order) {
  const validator = new OrderValidator();
  const enricher = new OrderEnricher();
  const transformer = new OrderTransformer();
  const handler = new OrderHandler();

  return handler.handle(
    transformer.transform(
      enricher.enrich(
        validator.validate(order)
      )
    )
  );
}

// AFTER: Via negativa - what can we remove?
function processOrder(order) {
  validateOrder(order);  // Just validate and process
  return saveOrder(order);
}
// Removed: enricher (data already there), transformer (unnecessary)

Barbell Architecture

┌─────────────────────────────────────────────────┐
│                BARBELL ARCHITECTURE             │
├───────────────────────┬─────────────────────────┤
│     SAFE (90%)        │     RISKY (10%)         │
├───────────────────────┼─────────────────────────┤
│ PostgreSQL            │ New graph DB experiment │
│ Proven auth library   │ Custom ML feature       │
│ Standard REST API     │ gRPC for new service    │
│ Monolith core         │ Isolated microservice   │
│ Synchronous flows     │ Event-driven experiment │
└───────────────────────┴─────────────────────────┘

Rule: Never bet the company on the risky side.
      But always have a risky side to learn from.

Skin in the Game Design

/**
 * SKIN IN THE GAME CHECKLIST:
 *
 * 1. Does the author of this code get paged when it fails?
 *    If no → Add to on-call rotation
 *
 * 2. Does the PM who requested this feature see failure metrics?
 *    If no → Add to their dashboard
 *
 * 3. Can this code harm users without harming the company?
 *    If yes → Misaligned incentives, redesign
 *
 * 4. Who bears the cost of technical debt?
 *    Should be same people who created it
 */

Anti-Patterns

Pattern	Taleb Problem	Antifragile Fix
"Optimize for efficiency"	Removes slack, creates fragility	Optimize for resilience
"Add a feature"	Additive thinking	Via negativa: what to remove?
"Best practices everywhere"	Fragile middle	Barbell: safe core + risky experiments
"Single source of truth"	Single point of failure	Redundancy at critical points
"Move fast and break things"	Unbounded downside	Move fast with bounded experiments
"Expert predictions"	Experts wrong about tails	Prepare for what you can't predict

Review Checklist

Before shipping:

• Is this fragile, robust, or antifragile?
• What can we remove? (via negativa)
• Is downside bounded? (small failures only)
• Do we have optionality? (can we change course)
• Is there redundancy at critical points?
• Do decision-makers have skin in the game?
• Are we in the fragile middle or at the barbell ends?

Taleb Score

Score	Meaning
10	Antifragile: gains from volatility, via negativa applied, bounded downside
7-9	Robust: survives stress, some optionality, reasonable redundancy
4-6	Fragile but aware: knows risks, has some mitigation
0-3	Fragile: optimized for calm, will break under stress

Key Quotes

"Wind extinguishes a candle and energizes fire. You want to be the fire and wish for the wind."

"The three most harmful addictions are heroin, carbohydrates, and a monthly salary."

"If you have more than one reason to do something, just don't do it."

"Don't tell me what you think, tell me what you have in your portfolio."

"The fragile wants tranquility, the antifragile grows from disorder."

Integration

Combine with:

• /failure - Understanding how past failures shape design
• /safety - Systematic safety for the "safe" end of barbell
• /security-mindset - Security as bounded-downside thinking