Resilience

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

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

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