sandgardenhq/preserving-productive-tensions

Preserving Productive Tensions

Overview

Some tensions aren't problems to solve - they're valuable information to preserve. When multiple approaches are genuinely valid in different contexts, forcing a choice destroys flexibility.

Core principle: Preserve tensions that reveal context-dependence. Force resolution only when necessary.

Recognizing Productive Tensions

A tension is productive when:

• Both approaches optimize for different valid priorities (cost vs latency, simplicity vs features)
• The "better" choice depends on deployment context, not technical superiority
• Different users/deployments would choose differently
• The trade-off is real and won't disappear with clever engineering
• Stakeholders have conflicting valid concerns

A tension needs resolution when:

• Implementation cost of preserving both is prohibitive
• The approaches fundamentally conflict (can't coexist)
• There's clear technical superiority for this specific use case
• It's a one-way door (choice locks architecture)
• Preserving both adds complexity without value

Preservation Patterns

Pattern 1: Configuration

Make the choice configurable rather than baked into architecture:

class Config:
    mode: Literal["optimize_cost", "optimize_latency"]
    # Each mode gets clean, simple implementation

When to use: Both approaches are architecturally compatible, switching is runtime decision

Pattern 2: Parallel Implementations

Maintain both as separate clean modules with shared contract:

# processor/batch.py - optimizes for cost
# processor/stream.py - optimizes for latency
# Both implement: def process(data) -> Result

When to use: Approaches diverge significantly, but share same interface

Pattern 3: Documented Trade-off

Capture the tension explicitly in documentation/decision records:

## Unresolved Tension: Authentication Strategy

**Option A: JWT** - Stateless, scales easily, but token revocation is hard
**Option B: Sessions** - Easy revocation, but requires shared state

**Why unresolved:** Different deployments need different trade-offs
**Decision deferred to:** Deployment configuration
**Review trigger:** If 80% of deployments choose one option

When to use: Can't preserve both in code, but need to document the choice was deliberate

Red Flags - You're Forcing Resolution

• Asking "which is best?" when both are valid
• "We need to pick one" without explaining why
• Choosing based on your preference vs user context
• Resolving tensions to "make progress" when preserving them IS progress
• Forcing consensus when diversity is valuable

All of these mean: STOP. Consider preserving the tension.

When to Force Resolution

You SHOULD force resolution when:

1. Implementation cost is prohibitive

   • Building/maintaining both would slow development significantly
   • Team doesn't have bandwidth for parallel approaches

2. Fundamental conflict

   • Approaches make contradictory architectural assumptions
   • Can't cleanly separate concerns

3. Clear technical superiority

   • One approach is objectively better for this specific context
   • Not "I prefer X" but "X solves our constraints, Y doesn't"

4. One-way door

   • Choice locks us into an architecture
   • Migration between options would be expensive

5. Simplicity requires choice

   • Preserving both genuinely adds complexity
   • YAGNI: Don't build both if we only need one

Ask explicitly: "Should I pick one, or preserve both as options?"

Documentation Format

When preserving tensions, document clearly:

## Tension: [Name]

**Context:** [Why this tension exists]

**Option A:** [Approach]
- Optimizes for: [Priority]
- Trade-off: [Cost]
- Best when: [Context]

**Option B:** [Approach]
- Optimizes for: [Different priority]
- Trade-off: [Different cost]
- Best when: [Different context]

**Preservation strategy:** [Configuration/Parallel/Documented]

**Resolution trigger:** [Conditions that would force choosing one]

Examples

Productive Tension (Preserve)

"Should we optimize for cost or latency?"

• Answer: Make it configurable - different deployments need different trade-offs

Technical Decision (Resolve)

"Should we use SSE or WebSockets?"

• Answer: SSE - we only need one-way communication, simpler implementation

Business Decision (Defer)

"Should we support offline mode?"

• Answer: Don't preserve both - ask stakeholder to decide based on user needs

Remember

• Tensions between valid priorities are features, not bugs
• Premature consensus destroys valuable flexibility
• Configuration > forced choice (when reasonable)
• Document trade-offs explicitly
• Resolution is okay when justified