What Didn't Work: Lessons from Failures and Dead Ends

Part 40 of 12-Week BusinessMath Series

1. Over-Engineered Type System (v0.1 Mistake)

The Code:

// DON’T DO THIS protocol FinancialInstrument { associatedtype CashFlowType associatedtype ValuationType func cashFlows() -> [CashFlowType] func value(discountRate: Double) -> ValuationType } protocol FixedIncomeInstrument: FinancialInstrument where CashFlowType == FixedCashFlow { var couponRate: Double { get } var maturity: Date { get } }
protocol EquityInstrument: FinancialInstrument where CashFlowType == DividendCashFlow { var dividendPolicy: DividendPolicy { get } }
// This went on for 15 protocols… 

• Complexity explosion: Users couldn’t figure out which protocol to conform to
• Rigid hierarchy: Real instruments don’t fit neat categories (convertible bonds are both equity and fixed income)
• PATs everywhere: Protocol with associated types made APIs painful
• Compile times: 45 seconds → 3 minutes

The Fix:

// DO THIS INSTEAD struct Bond { let faceValue: Double let couponRate: Double let maturity: Period
func price(yield: Double) -> Double { // Simple implementation, no protocol maze } 
}
struct Stock { let expectedReturn: Double let volatility: Double
func expectedPrice(horizon: Period) -> Double { // Different from Bond, that’s OK! } 
} 

2. Premature GPU Optimization (Month 2 Fiasco)

// Tried to GPU-accelerate even simple operations func npv(discountRate: Double, cashFlows: [Double]) -> Double { // Copy to GPU let gpuBuffer = device.makeBuffer(bytes: cashFlows, length: cashFlows.count * 8)
// Run Metal compute shader let commandBuffer = commandQueue.makeCommandBuffer()! // … 50 lines of Metal boilerplate …
// Copy result back return result 
} 

The Fix:

// Simple CPU version (fast enough for 99% of use cases) func npv
            
              (discountRate: T, cashFlows: [T]) -> T { cashFlows.enumerated().reduce(T.zero) { sum, pair in let (period, cashFlow) = pair return sum + cashFlow / T(1 + discountRate).pow(T(period + 1)) } }
              

            
// GPU version ONLY for specific use case (genetic algorithm with 10,000+ population) if populationSize > 1_000 && Metal.isAvailable { return gpuGeneticAlgorithm(…) } 

3. Magical Auto-Constraint Detection (Abandoned Feature)

The Idea:

// User writes this: let portfolio = Portfolio(assets: 50)
// Optimizer “magically” knows: // - Weights sum to 1 (it’s a portfolio!) // - No negative weights (you can’t short!) // - Max position size 20% (industry standard!)
let result = optimizer.optimize(portfolio) // No constraints specified 

• Surprises: Users didn’t know what constraints were applied (“Why can’t I short?”)
• Inflexible: Couldn’t handle non-standard portfolios (long-short, leverage)
• Debug nightmares: “Is it using my constraints or auto-detected ones?”
• False confidence: Users assumed optimizer knew their domain—it didn’t

The Fix:

// Make constraints explicit (even if verbose) let result = optimizer.minimize( objective, constraints: [ .sumToOne,      // User sees this is applied .longOnly,      // User sees this is applied .positionLimit(max: 0.20)  // User can change this ] ) 

4. Over-Abstracted Optimization Framework (Month 4 Rewrite)

The Code:

protocol OptimizationProblem { associatedtype Solution associatedtype Constraint: ConstraintProtocol func evaluate(_ solution: Solution) -> Double func constraints() -> [Constraint] }
protocol Optimizer { associatedtype Problem: OptimizationProblem func solve(_ problem: Problem) -> Problem.Solution }
// Now users have to implement 2 protocols + 3 associated types just to optimize 

• Cognitive load: Users spent 30 minutes reading docs before optimizing
• Boilerplate explosion: 50 lines of protocol conformance for 5 lines of actual logic
• Type system fights: Compiler errors like “Cannot convert value of type ‘Problem.Constraint’ to expected argument type…”
• Nobody asked for this: Solving a problem users didn’t have

The Fix:

// Just use closures func minimize
            
              ( _ objective: (T) -> Double, startingAt initial: T, constraints: [(T) -> Double] = [] ) -> T { // Simple, understandable, works }
              

            
// Usage is obvious let result = optimizer.minimize( { weights in portfolio.variance(weights) }, startingAt: equalWeights, constraints: [sumToOne, longOnly] ) 

5. Documentation Generation from Tests (Cool But Useless)

The Code:

// Tests with special comments func testNPVPositiveReturns() { /// @example NPV with positive returns /// @expectedResult Positive NPV indicates good investment let npv = npv(discountRate: 0.10, cashFlows: [-100, 30, 40, 50]) XCTAssertGreaterThan(npv, 0)  /// @assert “NPV must be positive for profitable investment” }
// Tool parses comments → generates docs 

• Docs were terrible: Reads like test code because it IS test code
• Maintenance hell: Change test → docs break, change docs → tool confused
• Nobody wanted it: Manual examples were clearer anyway
• Complexity: 500 lines of parsing code for marginal benefit

The Fix:

/// Calculate NPV for a series of cash flows. /// /// ## Example /// /// swift /// let npv = npv(discountRate: 0.10, cashFlows: [-100, 30, 40, 50]) /// // → 8.77 (positive NPV = good investment) ///  public func npv
            
              (discountRate: T, cashFlows: [T]) -> T { // Manual docs, clear and concise } 
            

6. Trying to Support Every Financial Standard (Scope Creep)

Why It Failed:

• Endless variations: Every country has accounting tweaks
• Domain expertise: Needed CPAs for each standard
• Maintenance burden: Standards change annually
• Users didn’t care: 95% just wanted US GAAP

The Fix:

• Support US GAAP thoroughly (what 95% of users need)
• Document how to extend for other standards
• Let users contribute IFRS/HGB if they need it

7. Type-Level Dimensional Analysis (Compile-Time Units)

The Code:

struct USD: UnitType {} struct Percentage: UnitType {} struct BasisPoints: UnitType {}
struct Quantity
              
                 { let value: Double }
              
// Compiler prevents mixing units! let price = Quantity
              
                (value: 100.0) let return = Quantity
                
                  (value: 0.10)
                
              
let x = price + return // ✗ Compile error: can’t add USD + Percentage 

• Conversion hell: Needed explicit conversions everywhere
• API complexity: Every function needed generic unit parameters
• User confusion: “Why can’t I just use Double?”
• Limited benefit: Caught maybe 2 bugs in 6 months of development

The Fix: Use runtime validation for critical conversions, rely on clear naming for the rest.

// Simple, clear, works func sharpeRatio(expectedReturn: Double, stdDev: Double) -> Double { expectedReturn / stdDev  // Clear from names what units are } 

The Meta-Lesson

I tried to be clever instead of simple. I tried to prevent every possible error instead of handling actual errors. I tried to support every use case instead of the common cases.

The pattern:

1. Identify problem
2. Design elaborate solution
3. Implement for 2 weeks
4. Realize it’s too complex
5. Delete it all
6. Write simple version in 2 hours
7. Simple version is better

Questions to Ask Before Adding Complexity

1. Is this solving a real problem users have? (Not just “wouldn’t it be cool if…”)
2. Can I solve this with existing features? (Closures > protocols, runtime checks > type gymnastics)
3. Will this make the API simpler or harder? (If harder, probably skip it)
4. Am I doing this because it’s fun or because it’s needed? (Be honest!)

Topics Covered: Over-engineering • Premature optimization • Magic abstraction • Scope creep • Type complexity • Simplicity wins

Final Week: [2 posts remaining] • [Final case study Thursday]