Exploring Alternatives

# Exploring Alternatives

## Overview

Don't settle for the first design you think of. Try multiple approaches, compare trade-offs, pick the best, THEN implement.

**Core principle:** Design is cheap to iterate. Code is expensive. Once you write code, emotional attachment makes it hard to throw away. Explore alternatives while iteration is still cheap.

**Violating the letter of this rule is violating the spirit of good design.**

## When to Use

**Always use before implementing:**
- Non-trivial features
- Complex algorithms
- System design decisions
- Refactoring approaches
- Architecture choices
- Data structure selection

**Especially when:**
- First idea feels complex
- Multiple viable approaches exist
- Stakes are high (production code, public APIs)
- Design will be hard to change later

**Warning signs you need this:**
- Jumping to implementation with first idea
- "This is the obvious way" (without considering alternatives)
- Solution feels forced or awkward
- Fighting the implementation
- Design keeps changing during coding

## The Exploration Process

### Step 1: Understand the Problem

**Before exploring solutions, clarify the problem:**

- What exactly are we solving?
- What are the constraints?
- What are the requirements?
- What are success criteria?

**If problem is unclear, exploring solutions is premature.**

### Step 2: Generate 2-3 Alternatives

**Don't stop at first idea. Generate at least 2 more.**

**Techniques for generating alternatives:**

1. **Different data structures:**
   - Array vs linked list vs tree vs hash table
   - List vs set vs dictionary

2. **Different algorithms:**
   - Iterative vs recursive
   - Brute force vs optimized
   - Different algorithmic approaches (sort-based vs hash-based)

3. **Different levels of abstraction:**
   - Direct implementation vs library
   - Custom code vs existing pattern
   - Simple specific vs generic flexible

4. **Different responsibility allocation:**
   - One class vs multiple
   - Function vs class
   - Inline vs extracted

5. **Different error handling:**
   - Exceptions vs return codes
   - Fail fast vs continue with defaults
   - Validate at boundary vs trust callers

**For each approach, sketch it in pseudocode or bullet points.**

### Step 3: Compare Trade-offs

**Evaluate each alternative against criteria:**

| Criterion | Alternative 1 | Alternative 2 | Alternative 3 |
|-----------|---------------|---------------|---------------|
| Simplicity | Simple | Complex | Medium |
| Performance | Fast | Slow | Medium |
| Maintainability | Easy to modify | Hard to change | Medium |
| Testability | Easy to test | Hard to test | Medium |
| Flexibility | Rigid | Very flexible | Some flex |
| Development time | Quick | Slow | Medium |

**Which criteria matter most for this problem?**

### Step 4: Pick the Best

**Choose based on:**
- Requirements (which criteria actually matter)
- Simplicity (default to simplest that meets requirements)
- Long-term maintainability (code is read 10x more than written)

**Document why you picked it:**
- "Chose approach 2 because performance is critical and measurements show approach 1 is too slow"
- "Cho