Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey

Overview

Rich Hickey’s RailsConf 2012 keynote argues that simplicity is a distinct, objective design goal—not the same as easy. He defines complexity as twisting/braiding multiple roles together, making understanding and change harder, and frames simplicity as the path to long-term architectural agility.

Core Concepts & Distinctions

Simplicity vs. Complex

• Simple: “one role” / one task per component; objectively testable and inspectable.
• Complex: multiple things “braided/tied together,” creating entanglement.

Simplicity vs. Easy

• Easy is about nearness and familiarity—relative to the person’s current knowledge and installed toolchain.
• “Easy” can still lead to complexity later if it’s easy to adopt now but hard to change later.

Objectivity

• Simplicity is presented as an objective property of the software structure, not a subjective preference.

The “Complexity Elephant” and Why It Matters

• As a system grows, the already-written software becomes a dominant force (“elephant”) that limits iteration speed.
• Even with good processes (testing, methodologies), entanglement/complexity eventually blocks progress.
• The key remedy is reducing the complexity of the software you already have, not only relying on process.

Architectural Agility Claim

• Hickey argues that architectural agility is primarily enabled by simplicity.
• When systems are fundamentally simple:
  • Substitution is easier (swap parts, run on different infrastructure).
  • Recombination is easier (use existing parts to solve new problems).
  • You can “move from here to there” without dragging an elephant through redesign.

What “Good Design” Is (Per the Talk)

Design is framed less as visual/plan-making and more as:

• Taking things apart
• Separating concerns into simple components

This approach creates opportunities for change by preventing entanglement.

Practical Guidance: How Simplicity Is “Made”

He argues you can make “the same software” with dramatically simpler approaches:

• Shift toward values and plain functions

  • Prefer functions over methods for simplicity, testability, and maintenance.
  • Keep state only where needed.

• Avoid unnecessary complexity sources

  • Reduce reliance on variables, complex switches/pattern matching vs. polymorphism.
  • Be cautious with syntax/DSLs because they add inherent complexity (meaning tied to order/position).
  • Treat loops and conditionals as complexity mechanisms that can complicate “work-order/logic” with data.

• Be wary of complex consistency models

  • Eventual consistency is called “incredibly complex” and should be chosen only when necessary.

Strong Critique: “Simplicity Is About the Programmer”

• He explicitly rejects the idea that simplicity is primarily about developer convenience (e.g., “gem install hairball” / adopting tools that are easy now).
• Tools may reduce immediate effort, but can become long-term “hairballs” that are hard to remove/change.
• Simplicity requires hard work up front, but yields greater change capability later.

Two Deep Examples of Complexity Sources

1) The “Order Problem”

• Order-dependent sequences (e.g., lists/tuples used as multi-field records) create hidden coupling:
  • Changes become error-prone because “what’s first?” matters everywhere.
• Preferred alternatives:
  • Use sets when order doesn’t matter.
  • Use maps/hashes for keyed data so meaning isn’t positional.
• Architectural implication:
  • Imperative / statement-ordered logic tends to break when reordered.
  • Chained calls “A then B then C” are harder to change than queue/message-style designs.

2) The “Information” Problem

• He criticizes wrapping data into “stupid classes” that add verbs/behavior around representation.
• He argues that information should remain data (e.g., associative structures) so it can be manipulated generically.
• Encapsulation is framed as mostly about implementation details; if data must be represented somewhere, encapsulating it as “verbby objects” often reduces flexibility.
• For moving toward “systems of systems” (e.g., services):
  • Internal code should already operate on data structures, because shifting to distributed systems (JSON/REST) is only natural when you program-with-data from the start.

Review/Guide Tutorial Angle

This isn’t a product review, but it functions as a design guide:

• Separating simplicity from ease
• Detecting entanglement (“complecting”) in day-to-day development
• Refactoring choices:
  • values/functions
  • maps/hashes
  • declarative/data-centric structures
  • avoiding order and information-wrapping pitfalls

Suggested “Self-Check” During Development

• During standups: ask whether the team has entangled/complected new things.
• Encourage conversations grounded in whether components are becoming twisted together.

Main Speaker / Source

• Rich Hickey (author and speaker; keynote: “Simplicity Matters”)