Lesson 4 of 7 20 min

The Subtractive Triad

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

The Three Questions

Every technical decision you make — every feature, every tool, every line of code — can be evaluated with three questions. Ask them in order:

# Question If the answer reveals a problem...
1 "Have I built this before?" Unify the duplicates
2 "Does this earn its existence?" Remove what doesn't
3 "Does this serve the whole?" Reconnect what fragments

That's it. Three questions. They reveal duplication, excess, and disconnection — the three things that obscure code.

Let's break each one down.

Question 1: DRY — "Have I built this before?"

You've heard of DRY (Don't Repeat Yourself). But most people misunderstand it.

DRY is not: "Never write similar code twice."
DRY is: "Every piece of knowledge should have one authoritative source."

The Quick Test

Ask: If I change one instance, must I change the other?

  • Yes → That's duplication. Unify them.
  • No → Not duplication. Leave them separate.

Try This Now

Look at your current project. Find two functions that do similar things. Ask the question. If one has to change when the other does, you've found a DRY violation.

In Automation

Before adding a tool to your automation layer:

// Someone suggests adding task_create()...
task_add()      // Already creates tasks
task_create()   // Would also create tasks (???)

// Ask: Have I built this before?
// Answer: Yes. task_add already does this.
// Action: Don't add task_create. One tool per capability.

Question 2: Rams — "Does this earn its existence?"

Named for Dieter Rams, the designer who said: "Weniger, aber besser" — Less, but better.

Every feature, every tool, every option must justify its presence. If it can't, remove it.

The Existence Test

Four questions to ask about any proposed feature:

  1. What happens if I don't add this? (Often: nothing bad)
  2. Who asked for this? (Often: no one)
  3. When was this last needed? (Often: never)
  4. What's the simplest version? (Often: much simpler)

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

Try This Now

Look at a feature you're working on. Ask: Who asked for this? When was it last needed?

If you can't answer, the feature might not earn its existence.

In Automation

// Proposed tools for a task tracker:
task_add         ✓ Essential — can't manage tasks without creating them
task_list        ✓ Essential — need to see what exists
task_complete    ✓ Essential — core workflow action
task_remove      ✓ Essential — need to clean up

task_archive     ✗ Who asked? (no one)
task_priority    ✗ When needed? (never came up)
task_color       ✗ Does it serve the workflow? (no)

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

Question 3: Heidegger — "Does this serve the whole?"

The deepest question. Named for the philosopher who observed: you understand parts through the whole, and the whole through parts.

Zoom out. Does this feature, this tool, this code — does it serve the system's purpose?

Signs of Disconnection

  • Orphaned code: A function nothing calls
  • Misaligned naming: Tool says "item" but the system says "task"
  • Wrong placement: Business logic in the transport layer
  • Scope creep: A tool that does something outside its system's purpose

Try This Now

Pick a file in your project. Ask: What system does this serve? Then look at each function. Does every function serve that system?

If you find one that doesn't fit, you've spotted disconnection.

In Automation

Your task tracker serves one workflow: "Manage tasks through conversation."

Does task_add serve this?     → Yes, core workflow
Does task_list serve this?    → Yes, core workflow
Does export_csv serve this?   → No — that's a different workflow

export_csv might be useful, but it doesn't serve this system. It belongs somewhere else (or nowhere).

Why This Order?

DRY is fastest. Does it exist? Yes or no. Quick to check.

Rams requires judgment. You have to evaluate need vs. excess.

Heidegger is deepest. You have to understand the whole system.

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

A Complete Example

Scenario: Someone suggests adding task_archive to your Task Tracker.

Question 1 (DRY): Have I built this before?

  • task_complete already marks tasks done
  • task_list can filter by status
  • "Archive" might just be filtering, not a new capability

Question 2 (Rams): Does task_archive earn its existence?

  • What happens if I don't add it? Users filter completed tasks instead
  • Who asked for this? The actual need was "hide completed tasks"
  • What's the simplest version? Add a status filter to task_list

Decision: Don't add task_archive. Extend task_list with a filter parameter.

The Triad eliminated a feature before it was built. That's the point.

Resources

If you want to go deeper:

Try This in Claude Code

Copy this prompt and paste it into Claude Code:

I'm designing a simple task tracker. Someone suggested adding these tools:
- task_add
- task_list  
- task_complete
- task_remove
- task_archive
- task_priority
- task_color

Apply the Subtractive Triad to this list. Which tools earn their existence? 
Which should be cut? Walk through DRY, Rams, and Heidegger for each one.

What you're practicing: Using the Triad to make real design decisions. This is the exact exercise you'll face in the capstone.

What you should see: Claude Code should keep the first four tools and question the last three. If it keeps all of them, push back: "Apply Rams more strictly. Who asked for task_color?"

Lesson Complete

You've learned:

  • ✓ DRY: "Have I built this before?" → Unify
  • ✓ Rams: "Does this earn its existence?" → Remove
  • ✓ Heidegger: "Does this serve the whole?" → Reconnect
  • ✓ Ask them in order — shallow to deep

The goal you achieved: You can evaluate any proposed feature using the three questions.