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 interface
• Allow you to work at problem level, not implementation level

Example:

# ❌ Low-level, complex
current_font.attribute = current_font.attribute or 0x02

# ✅ High-level, simple
current_font.set_bold_on()

Working with fonts (problem domain) > manipulating bit fields (implementation domain)

Desirable Design Characteristics

All aimed at managing complexity:

| Characteristic | Why It Reduces Complexity |

…