Lesson 4 of 7 20 min

The Subtractive Triad

Three questions that guide every decision: DRY, Rams, Heidegger.

Three Questions for Every Decision

The Subtractive Triad is your evaluation framework. For any technical choice, ask these three questions in sequence:

Level Question Action
DRY "Have I built this before?" Unify
Rams "Does this earn its existence?" Remove
Heidegger "Does this serve the whole?" Reconnect

Level 1: DRY (Implementation)

Question: Have I built this before?

DRY means "Don't Repeat Yourself" — but it's commonly misunderstood.

DRY is not: "Never write similar code twice."
DRY is: "Every piece of knowledge must have a single, authoritative representation."

The Test

If one instance changes, must the other change too?

  • Yes → Unify them (DRY violation)
  • No → Leave them separate (not a violation)

In Automation

Before adding a tool to your automation layer, ask: Does this capability already exist?

// BAD: Separate tools that duplicate knowledge
task_add()      // Creates a task
task_create()   // Also creates a task (???)

// GOOD: One authoritative tool per capability
task_add()      // The only way to create tasks

Level 2: Rams (Artifact)

Question: Does this earn its existence?

Named for Dieter Rams: "Weniger, aber besser" — Less, but better.

The Existence Test

  1. What happens if I don't add this?
  2. Who asked for this?
  3. When was this last needed?
  4. What's the simplest version?

If the answers are "nothing much," "no one," "never," and "much simpler" — remove it.

In Automation

Every tool in your automation layer must earn its place:

// Proposed tools for a task tracker:
task_add         ✓ Essential
task_list        ✓ Essential
task_complete    ✓ Essential
task_remove      ✓ Essential
task_archive     ✗ Does this earn existence? (filtering serves same need)
task_priority    ✗ Does this earn existence? (not requested)
task_color       ✗ Does this earn existence? (definitely not)

Four tools is enough. Every extra tool is complexity that must be justified.

Level 3: Heidegger (System)

Question: Does this serve the whole?

Named for Martin Heidegger, who observed: You understand parts through the whole, and the whole through parts.

Seeing Disconnection

  • Orphaned code: Tools nothing uses
  • Fragmented boundaries: Responsibilities split illogically
  • Misaligned naming: Tool says "item" when system says "task"
  • Wrong placement: Business logic in the transport layer

In Automation

Your automation layer serves a workflow. Does each tool serve that workflow?

User's workflow: "Manage my tasks through conversation"

Does task_add serve this?     → Yes, essential to the workflow
Does task_list serve this?    → Yes, essential to the workflow
Does export_csv serve this?   → No, serves a different workflow

Why This Order?

DRY is fastest — Code exists or it doesn't. Quick to check.
Rams requires judgment — You must evaluate need vs. excess.
Heidegger is deepest — You must understand the whole system.

Start shallow, spiral deeper. If DRY eliminates the decision, you don't need Rams. If Rams eliminates the feature, you don't need Heidegger.

A Complete Example

Scenario: "Add a task_archive tool to the Task Tracker."

Level 1: DRY

Ask: Have I built this before?
Finding: task_complete marks tasks done. task_list can filter by status.
Insight: "Archive" might be filtering, not a new capability.

Level 2: Rams

Ask: Does task_archive earn its existence?
Finding: The user wants to "hide completed tasks" — that's filtering.
Decision: Add a status parameter to task_list instead of a new tool.

Decision ends here. Rams eliminated the proposed tool.

Resources