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:

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"
• "Chose approach 1 because simplicity matters more than flexibility we don't need yet"

Step 5: Implement

Only after comparing alternatives, implement the chosen approach.

If implementation fights you → return to Step 2. You might have picked wrong alternative.

Quick Reference

…