Concept
The Extraction Principle
The best abstractions emerge from extracting patterns you've already implemented multiple times, not from anticipating future needs.
Don't abstract prematurely. Let patterns emerge.
The anti-pattern
When starting a new project, it's tempting to build "the right way" from the start—creating abstractions, utilities, and frameworks for problems you haven't encountered yet.
This almost always leads to:
- Over-engineered solutions for simple problems
- Abstractions that don't fit real use cases
- Wasted time on code you'll rewrite anyway
The extraction approach
Instead:
- Build the first implementation directly, even if it's ugly
- Build the second implementation separately, noticing similarities
- Build the third implementation and extract the common pattern
By the third time, you understand the real requirements. The abstraction emerges naturally from concrete examples.
Why it works
Premature abstraction is speculation. Extraction is observation.
You can't predict the future, but you can recognize patterns in the past. The extraction principle uses hindsight as a feature, not a bug.
When to break this rule
Some abstractions are well-established patterns (auth, data fetching, routing). Use existing solutions for those. The extraction principle is for your domain-specific code.