tjboudreaux/thinking-via-negativa

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:

## 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:

| 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:

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:

## 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

## 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

## 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

## 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

## 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

## 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

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

## Current State
[Description of what exists]

## Candidates for Removal

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

### Category 2: Low-Value High-Cost
| Element | Value Provided | Maintenance Cost | Ratio |
|---------|---------------|------------------|-------|
| | | | |

### Category 3: Redundant
| Element | Duplicated By | Removal Path |
|---------|---------------|--------------|
| | | |

## Removal Priority
1. [Element] - [Why first]
2. [Element] - [Why second]

## Removal Plan
| Element | Week | Monitor | Rollback |
|---------|------|---------|----------|
| | | | |

## Expected Benefits
- Reduced complexity: [Measure]
- Freed resources: [Measure]
- Improved focus: [Measure]

The Lindy Connection

Via Negativa aligns with Lindy:

• Old things that have survived removal attempts are robust
• New additions are fragile, unproven
• Subtracting recent additions is lower risk than adding new things

Verification Checklist

• [ ] Asked "what can we remove?" before "what should we add?"
• [ ] Identified candidates for removal in multiple categories
• [ ] Evaluated usage/value of removal candidates
• [ ] Planned gradual removal with monitoring
• [ ] Considered second-order effects of removal
• [ ] Resisted the urge to add when subtraction would work

Key Questions

• "What can we remove instead of add?"
• "What would happen if we stopped doing this?"
• "What's the maintenance cost of this existing thing?"
• "Is this complexity earning its keep?"
• "What should we stop doing?"
• "What would we not build if starting from scratch?"

Taleb's Wisdom

"The first principle of iatrogenics: we do not need evidence of harm to claim that a treatment is harmful; we need evidence of benefit to claim it is not harmful."

Applied to software: We don't need evidence that a feature is actively harmful to remove it; we need evidence it provides benefit to keep it.

"Via Negativa is more powerful than Via Positiva: omission does less harm than commission."

Removing is safer than adding. Every addition has unknown side effects. Removal of recent additions reverts to a known-good state. When in doubt, subtract.

"The best way to live is to maximize the number of decisions not made."

Reduce decisions through simplification. Fewer features = fewer decisions to make. Fewer processes = fewer coordination points. Simpler is more robust.