On Simplicity and Software Craft

In software development, complexity is like friction: it creeps into systems silently and continuously. Unless an engineer actively pushes back against it, systems inevitably grow larger, harder to understand, and more brittle with every passing release.

Essential vs. Accidental Complexity

In his seminal 1986 paper No Silver Bullet, Fred Brooks separated complexity into two distinct categories:

• Essential complexity: The difficulty inherent in the actual problem you are trying to solve (e.g. accounting rules, physical laws, user workflows).
• Accidental complexity: The difficulty introduced by our tools, frameworks, layers of abstraction, and self-imposed architectural overhead.

The Cost of "Future-Proofing"

Engineers often introduce complex abstractions in anticipation of future requirements that never arrive. We build generic plugin architectures, multi-tiered microservice topologies, and elaborate state managers for applications that could comfortably run as a single static file or a lightweight monolithic script.

"The cheapest, fastest, and most reliable components are the ones that aren't there." — Gordon Bell

Every dependency you add is a debt you commit to servicing: breaking updates, security patches, deprecation warnings, and mental overhead. The truly robust software of our era—SQLite, curl, plain text protocols—endures because it respects the virtue of minimalism.

Practicing Simplicity

Simplicity is not laziness; it is rigorous discipline. It takes far more effort to design a simple interface than a complicated one. To practice simplicity:

1. Choose boring technology: Use tools that are mature, well-understood, and battle-tested.
2. Eliminate before optimizing: Before making code faster or more abstract, ask if you can delete it entirely.
3. Prefer explicit code over clever magic: Code is read far more often than it is written. Optimize for readability six months from now.