Reducing Complexity

# Reducing Complexity

## Overview

**Managing complexity is the most important technical topic in software development.** All other technical goals—performance, features, elegance—are secondary to managing complexity.

**Core principle:** "There are two ways of constructing a software design: one way is to make it so simple that there are *obviously* no deficiencies, and the other is to make it so complicated that there are no *obvious* deficiencies." - C.A.R. Hoare

**Always choose the first way.**

## When to Use

**Use as guiding principle for EVERY technical decision:**
- Design decisions (class structure, subsystems, interfaces)
- Implementation decisions (algorithms, data structures)
- Refactoring decisions (what to simplify)
- Architecture decisions (how to partition system)
- Code review (primary evaluation criterion)

**Warning signs of complexity overload:**
- Can't keep design in mind all at once
- Need to understand entire system to change one part
- Applying methods mechanically without knowing why
- Code works but you're not sure how
- Difficult to explain how code works
- Many edge cases and special conditions
- Deep nesting (if inside if inside if...)
- Long parameter lists (> 7 parameters)
- Large routines that do many things
- Classes with unclear purpose

## Two Types of Complexity

### Essential Complexity

Inherent in the real-world problem itself. Can't be eliminated, only managed.

**Examples:**
- Interfacing with complex, disorderly real world
- Identifying all dependencies and exception cases
- Solutions that must be exactly correct, not approximately
- Intricate interactions between real-world entities

**Approach:** Minimize what anyone's brain must deal with at one time.

### Accidental Complexity

Complexity we introduce through our design and implementation choices. CAN be eliminated.

**Examples:**
- Clever abstractions that obscure meaning
- Unnecessary layers of indirection
- Over-engineering for hypothetical futures
- Complex solutions to simple problems
- Inconsistent interfaces
- Global variables creating hidden dependencies
- Poor naming making code cryptic

**Approach:** Keep accidental complexity from needlessly proliferating.

## How to Attack Complexity

**Two fundamental approaches, three practical strategies:**

1. **Minimize essential complexity** anyone must deal with at once
2. **Keep accidental complexity** from proliferating

**Implemented through three strategies:**

### Strategy 1: Break Into Simple Pieces

**Dijkstra's insight:** No one's skull is big enough to contain a modern program. Organize programs so you can safely focus on one part at a time.

**Think of it as mental juggling:** More mental balls to keep in air = more likely to drop one = design or coding error.

**At each level:**
- System → Subsystems
- Subsystem → Classes
- Class → Routines
- Routine → Statements

**Goal:** Make each piece simple enough to understand fully in isolation.

### Strategy 2: Minimize What You Must Understand At Once

Good design lets you safely IGNORE most of the program while working on any one part.

**Questions to ask:**
- Can I understand this routine without understanding the whole system?
- Can I modify this class without affecting others?
- Can I focus on this subsystem without knowing internals of others?

**If answer is no:** Design isn't doing its job. Increase encapsulation, reduce coupling.

### Strategy 3: Hide Complexity Behind Abstractions

**Each abstraction should:**
- Present a simple, consistent interface
- Hide messy details behind that