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:

Implementation cost is prohibitive

• Building/maintaining both would slow development significantly

• Team doesn't have bandwidth for parallel approaches

Fundamental conflict

• Approaches make contradictory architectural assumptions

• Can't cleanly separate concerns

Clear technical superiority

• One approach is objectively better for this specific context

• Not "I prefer X" but "X solves our constraints, Y doesn't"

One-way door

• Choice locks us into an architecture

• Migration between options would be expensive

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