thinking-via-negativa

What this skill does

# Via Negativa

## Overview

Via Negativa, articulated by Nassim Taleb in "Antifragile," is the principle that improvement often comes from subtraction rather than addition. We're biased toward adding (features, processes, complexity) when removing (bugs, friction, unnecessary work) often provides more value with less risk.

**Core Principle:** Focus on what to remove, not what to add. Subtraction is more robust than addition.

## When to Use

- System simplification
- Process improvement
- Feature prioritization (what NOT to build)
- Performance optimization
- Reducing technical debt
- Personal productivity
- Decision-making (what to avoid)
- Code review (what to delete)

Decision flow:

```
Trying to improve something?
  → First instinct is to add? → yes → PAUSE, CONSIDER SUBTRACTION
  → Can you achieve the goal by removing instead? → yes → REMOVE FIRST
  → Is current complexity necessary? → no → SIMPLIFY VIA NEGATIVA
```

## When NOT to Use

- **Never subtract a load-bearing control, test, validation, guard, or safety check** just because it's "extra complexity." Removal is only low-risk when the thing is genuinely unused or redundant. A test you don't understand, an error handler, a rate limiter, an auth check, or a retry are presumed load-bearing — prove they're dead before deleting. The whole "subtraction is safe" claim holds only for things that provide no benefit.
- **Not when the addition is genuinely required** to meet a real, demonstrated need. Via negativa fights the *reflex* to add; it doesn't forbid all addition.
- **Don't delete to hit an aesthetic "less is more" target** without checking what each element does — confirm non-use with evidence (usage data, dead-code analysis, removing it in a branch and watching), not assumption.

## Trigger Card

When about to add a feature, layer, or process to fix a problem:

1. **Ask: "What can I remove instead?"** — before adding, scan for something to subtract that would have the same or better effect.
2. **Identify the highest-cost, lowest-usage candidates** — what's consuming resources (code, process, dependency) but delivering the least value?
3. **Remove the simplest one first** — subtraction is asymmetric: removing is safer than adding because you can always add back. Test by removing it in a branch and seeing what breaks.

Don't delete to hit an aesthetic target without checking what each element does — confirm non-use with evidence, not assumption. If the addition is genuinely required for a real, demonstrated need, add it — via negativa fights the reflex to add, not all addition.

## The Via Negativa Process

### Step 1: Identify What to Eliminate

Instead of "What should we add?", ask:

```
- What's not working that we should remove?
- What's causing harm we should stop?
- What's unnecessary complexity we should eliminate?
- What's outdated that we should delete?
```

### Step 2: Catalog Candidates for Removal

List elements that might be subtracted:

```markdown
## Candidates for Removal

Code:
- Dead code (unreachable)
- Deprecated features (still running)
- Unused dependencies
- Redundant abstractions

Process:
- Meetings that don't produce decisions
- Approval steps that don't add value
- Reports no one reads
- Alerts no one acts on

Features:
- Low-usage functionality
- Legacy features maintained "just in case"
- Edge cases that complicate the core
```

### Step 3: Evaluate Impact of Removal

For each candidate:

```markdown
| Element | Usage | Maintenance Cost | Risk of Removal | Value of Removal |
|---------|-------|------------------|-----------------|------------------|
| Feature X | 0.1% of users | 20 hrs/month | Low | High |
| Meeting Y | 8 people | 4 hrs/week | None | High |
| Process Z | 5 approvers | 2 days/request | Medium | Medium |
```

### Step 4: Remove with Monitoring

Subtract and verify no harm:

```markdown
Week 1: Remove Feature X for 10% of users
Week 2: Monitor complaints, metrics
Week 3: If no issues, remove for 50%
Week 4: Full removal and code deletion
```

## Via Negativa Patterns

### Subtractive Design

Add by removing:

```
Goal: Make the product easier to use
Additive approach: Add tutorial, tooltips, help section
Via Negativa: Remove confusing features, simplify flow, delete options

Often more effective:
- Fewer choices = easier decisions
- Less surface area = less to learn
- Simpler UI = faster adoption
```

### The Pruning Principle

Healthy growth requires pruning:

```
Codebase:
- Every feature has maintenance cost
- Old features create complexity tax
- Pruning unused code enables healthier growth

Team:
- Every process has coordination cost
- Old processes accumulate like barnacles
- Pruning enables focus on what matters
```

### Harm Reduction Over Benefit Addition

Removing bad is often more impactful than adding good:

```
Performance:
- Removing one slow query helps more than adding one cache
- Eliminating N+1 beats adding read replicas
- Deleting unused indexes beats adding new ones

Health (Taleb's domain):
- Removing sugar helps more than adding supplements
- Stopping smoking beats starting exercise
- Eliminating stress beats adding meditation
```

### The 80/20 Removal

Remove the 80% that provides 20% of value:

```markdown
## Feature Usage Analysis

| Feature | Users | Revenue | Maintenance |
|---------|-------|---------|-------------|
| Core A | 90% | 70% | 20% |
| Core B | 85% | 25% | 15% |
| Edge C | 5% | 3% | 25% |
| Edge D | 2% | 2% | 40% |

Via Negativa: Remove Edge C and D
Result: 65% less maintenance for 5% of value
        Enables focus on Core A and B
```

## Application Areas

### Code

```markdown
## Via Negativa Code Review

Before adding new code, ask:
1. Can we solve this by removing existing code?
2. Is there dead code to delete?
3. Are there unused imports/dependencies?
4. Is there duplication to consolidate?
5. Are there unnecessary abstractions?

Rule: Every PR should delete at least as much as it adds
      (aspirational, not mandatory)
```

### Process

```markdown
## Via Negativa Process Audit

List all recurring processes:
- Daily standup (15 min/day × 8 people = 10 hrs/week)
- Sprint planning (2 hrs × 8 people = 16 hrs/sprint)
- Weekly status report (2 hrs to write)
- Monthly review (4 hrs × 5 people = 20 hrs/month)

For each, ask:
- What happens if we stop?
- Can we reduce frequency?
- Can we reduce attendees?
- Can we reduce duration?

Often: Half the meetings, half the reports = more productive
```

### Features

```markdown
## Via Negativa Product Strategy

Instead of roadmap of additions, create:

## Sunset List
| Feature | Usage | Decision | Timeline |
|---------|-------|----------|----------|
| Export to CSV | 0.5% | Remove | Q2 |
| Legacy API v1 | 2% | Deprecate | Q3 |
| Advanced filters | 3% | Simplify | Q2 |

## Maintenance Liberation
Removing 3 features frees 2 engineers for core work

## Simplicity Gains
- Fewer code paths to test
- Smaller attack surface
- Easier onboarding
- Faster development
```

### Personal Productivity

```markdown
## Via Negativa for Focus

Don't add:
- More productivity apps
- More systems
- More commitments

Instead remove:
- Notifications
- Unnecessary meetings
- Low-value tasks
- Context switching
- Decision fatigue (reduce choices)

"Stop doing" list > "To do" list
```

### Architecture

```markdown
## Via Negativa Architecture Review

Before adding complexity, audit existing:

Services to consolidate:
- Microservice A and B do similar things → Merge
- Service C has one caller → Inline

Dependencies to remove:
- Library X is used for one function → Write function
- Framework Y is overkill → Use lighter alternative

Layers to eliminate:
- Abstraction that has one implementation → Remove
- API that wraps another API identically → Direct call
```

## Via Negativa Template

```markdown
# Via Negativa Analysis: [System/Process/Product]

## Current State
[Description of what exists]

## Candidates for Removal

### Category 1: Unused/Dead
| Element | Evidence of Non-Use | Remov