Simple Versus Easy
Choose fewer dependencies even when building them takes more effort
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 98%
Drawing on programmer Rich Hickey, Sivers separates easy from simple. Easy means near at hand or already familiar; simple means not braided together with other things. A framework, hire, service, marriage, or delegation can therefore be easy to adopt while making the resulting system objectively complex. Start by naming the exact outcome, then map what each candidate solution binds you to: people, schedules, services, rules, and maintenance. Strip away norms and decorative features, learn enough fundamentals to build a direct route, and prefer the workable option with fewer entanglements. The model does not claim that the simplest-looking first move always wins. Ferriss presses the need to inspect second- and third-order effects so simplification does not merely relocate complexity into the future.
Origin
Rich Hickey presented the simple-versus-easy distinction for programmers; Derek Sivers applied it to business and life on The Tim Ferriss Show.
Core principles
- 01Easy and hard are subjective measures of familiarity
- 02Simple and complex describe how tightly something is bound to dependencies
- 03An easy setup can create an objectively complex system
- 04Learning fundamentals can make a simple approach easier to execute
- 05Direct routes preserve changeability and independence
How to run it
- 1
Name the outcome
State what must actually happen without describing the conventional solution.
Pro tip Use a concrete output, such as getting one calendar entry into one database.
- 2
Map the bindings
List the people, services, schedules, rules, and technologies each option would bind together.
Watch out A one-click installation can conceal a large dependency graph.
- 3
Separate easy from simple
Mark which option merely feels familiar and which option actually stands more independently.
Pro tip Treat familiarity as a personal property, not a structural property of the system.
- 4
Learn the fundamentals
Acquire enough underlying knowledge to execute the direct option without adopting an oversized solution.
- 5
Trace later effects
Project how each design changes maintenance, reversibility, lifestyle, and future choices.
Pro tip Ask whether apparent simplicity now creates difficult-to-undo complexity later.
- 6
Choose low entanglement
Select the simplest workable route, accepting extra initial effort when it buys meaningful independence and changeability.
In the wild
Sivers paraphrases Hickey's example that a programmer can type a short install command and acquire a massive framework. The installation is easy, but the project is now intertwined with a complicated system.
→ The distinction exposes convenience as separate from low complexity.
When programming, Sivers asks whether he needs layers of JavaScript, styling, and visual effects when the real outcome is only to put a calendar entry with a time into a database.
→ Defining the output reveals a smaller implementation path.
Common mistakes
Calling familiar simple
Something can feel easy because you know it while remaining structurally bound to many other things.
Ignoring ripple effects
A direct first-order move can impose lifestyle constraints or difficult-to-reverse complexity later.
Is it for you?
Best for
Builders and decision-makers comparing a familiar packaged solution with a more independent direct approach.
Not ideal for
Choices where avoiding a dependency creates greater irreversible risk or hidden downstream complexity.
From the transcript
“simple comes from Simplex which means it is not bound to other things it stands alone”
“it can be really hard to make something simple”
“what's the real outcome I'm after what's the real point of this”
From the episode
#777: Derek Sivers, Philosopher-Entrepreneur — The Greatest Year of His Life
Derek Sivers