System Design (LLD)The Cost of Wrong Abstractions

The Cost of Wrong Abstractions

LevelIntermediate

Duration90 mins

TopicThe Cost of Wrong Abstractions

3 / 4

Premature Abstraction — The Timing Problem

The Danger of Abstracting Too Soon

We've explored over-abstraction (too much) and under-abstraction (too little). But there's a third failure mode that deserves separate treatment: premature abstraction—creating the right abstraction at the wrong time.

Premature abstraction is particularly insidious because it can look correct. The abstraction might even be the perfect solution—for a problem that doesn't exist yet, may never exist, or will exist in a different form than anticipated.

What You Will Learn

By the end of this page, you will understand why timing matters in abstraction decisions, the costs of abstracting before you understand the problem, and practical strategies for developing the patience to wait for clarity before generalizing.

What Makes Abstraction Premature

Abstraction is premature when it's based on speculation rather than evidence. When you generalize before understanding the specific cases, you're guessing at what the abstractions should be—and guesses about future requirements are notoriously unreliable.

Premature abstraction typically manifests in these patterns:

Characteristics of Premature Abstraction

•First-Version Generalization — Abstracting before you've written the first concrete implementation. You can't know what to abstract before you know what works.
•Predicted Variations — Building interfaces for variations that might exist. "We might need different payment providers someday."
•Engineering for Scale Before Users — Designing for millions of users when you have hundreds. Scaling problems are specific; you can't solve them in advance.
•Architectural Patterns Without Problems — Applying microservices, event sourcing, or CQRS because they're "best practices," not because your system needs them.
•Framework Extraction Too Early — Extracting a reusable framework after building only one or two applications in the space.

The Core Insight

Abstraction captures patterns. Patterns only become visible through repetition and experience. Before you've seen the pattern multiple times, any abstraction is speculation about what the pattern IS—and speculation is usually wrong.

Why Timing Matters in Abstraction

The timing of abstraction matters because abstractions are hard to change once established. An abstraction becomes a contract—other code depends on it, tests verify it, documentation describes it. Changing the contract later is expensive.

Consider the lifecycle of an abstraction:

Abstraction Lifecycle and Change Cost
Stage	Description	Cost to Change
Creation	Abstraction is defined and first used	Minimal (just delete it)
Adoption	Multiple consumers depend on abstraction	Moderate (must update consumers)
Entrenchment	Abstraction shapes architectural decisions	High (requires significant refactoring)
Petrification	Changing abstraction would break external contracts	Very High (may be practically impossible)

The wrong abstraction locks you in:

When you abstract prematurely, you commit to a generalization before understanding the specific cases. When reality diverges from your predictions (which it almost always does), you face a dilemma:

Adapt the implementation to fit the wrong abstraction — This creates awkward code that fights against the abstraction's assumptions.
Extend the abstraction to cover new cases — This bloats the abstraction with special cases, destroying its coherence.
Replace the abstraction entirely — This requires updating all consumers and may introduce regressions.

All three options are costly. None would have been necessary if you'd waited for clarity before abstracting.

The Wisdom of Waiting

Delaying abstraction isn't procrastination—it's information gathering. Every concrete implementation teaches you about the problem domain. When you finally abstract, you're working with real knowledge instead of speculation.

The Costs of Premature Abstraction

Premature abstraction combines the costs of over-abstraction with the additional cost of being wrong. Here are the specific ways it damages projects:

The Cost Dimensions of Premature Abstraction

•Immediate Overhead Without Benefit — You pay the complexity cost of abstraction (indirection, interfaces, generalization) before any benefit materializes. If the predicted variations never arrive, the cost is pure loss.
•Wrong Flexibility Points — You make the system flexible in places that don't need to change, while the parts that actually need to change are hardcoded around the wrong abstraction.
•Delayed Understanding — By generalizing too soon, you stop learning about the specific cases. The abstraction obscures the concrete behavior you need to understand.
•Constraint on Future Solutions — The premature abstraction constrains future design decisions. Better approaches may be impossible because they'd require abandoning the abstraction.
•Team Cognitive Load — Team members must understand the abstraction before they can work in the area, even though the abstraction doesn't yet solve a real problem.
•Maintenance of Unused Generality — Tests, documentation, and code reviews all carry the burden of abstraction that provides no value.

The speculation tax:

Think of premature abstraction as a tax on speculation. Every assumption you embed in an early abstraction is a bet. If the bet loses, you pay the cost of removing or working around the wrong abstraction. If the bet wins, you've merely avoided duplication you didn't have yet.

The expected value is negative: the cost of wrong abstraction exceeds the cost of delayed abstraction, multiplied by the probability of being wrong (which, for speculation, is high).

The Compounding Problem

Premature abstractions attract premature extensions. Once you have a speculative interface, developers add speculative methods "for consistency." Each addition deepens commitment to the wrong direction and makes correction harder.

Case Study: The Premature Plugin System

Let's examine a realistic example of premature abstraction and its consequences. A team builds an e-commerce system and anticipates they might need multiple payment providers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Year 1: Team anticipates multiple payment providers
// They build a full abstraction layer before having any
 
interface PaymentProvider {
    initialize(config: ProviderConfig): Promise<void>;
    createPayment(amount: Money, metadata: PaymentMetadata): Promise<PaymentIntent>;
    confirmPayment(intentId: string): Promise<PaymentResult>;
    refundPayment(paymentId: string, amount?: Money): Promise<RefundResult>;
    listTransactions(filter: TransactionFilter): Promise<Transaction[]>;
    getProviderInfo(): ProviderInfo;
}
 
interface PaymentProviderFactory {
    create(providerType: ProviderType): PaymentProvider;
    register(type: ProviderType, factory: () => PaymentProvider): void;
}
 
class PaymentService {
    constructor(
        private providerFactory: PaymentProviderFactory,
        private providerRegistry: ProviderRegistry,
        private configLoader: ProviderConfigLoader
    ) {}
    
    async processPayment(request: PaymentRequest): Promise<PaymentResult> {
        const providerType = this.determineProvider(request);
        const provider = this.providerFactory.create(providerType);
        const config = await this.configLoader.load(providerType);
        await provider.initialize(config);
        const intent = await provider.createPayment(request.amount, request.metadata);
        return provider.confirmPayment(intent.id);
    }
}
 
// 500 lines of abstractions, factories, registries...
// For a single Stripe implementation that took 50 lines

Three years pass. What happened?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Year 3: Reality Check
 
// The business still only uses Stripe
// But now they need:
// - Apple Pay (different flow, not provider-based)
// - Buy Now Pay Later (requires checkout session, breaks interface)
// - Subscriptions (completely different model)
// - Regional routing (not provider selection)
 
// The premature abstraction:
// 1. Assumed payment methods would be interchangeable (wrong)
// 2. Assumed a factory pattern would handle selection (wrong)
// 3. Didn't anticipate flow differences (partially-confirmed payments, delayed)
// 4. Made it hard to add Apple Pay (it's not a "provider")
 
// The team now faces:
// - Rewriting the abstraction to accommodate real requirements
// - Or hacking around it with special cases
// - 500 lines of never-used generality wasted
// - Wrong mental model embedded in the codebase

What should they have done instead?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// Year 1: Just use Stripe directly
 
class PaymentService {
    constructor(private stripe: Stripe) {}
    
    async processPayment(amount: Money, customer: Customer): Promise<PaymentResult> {
        const intent = await this.stripe.paymentIntents.create({
            amount: amount.cents,
            currency: amount.currency,
            customer: customer.stripeId,
        });
        
        return {
            id: intent.id,
            status: intent.status,
            amount: amount,
        };
    }
}
 
// 50 lines, clear, directly testable
// When/if they need PayPal, they can abstract then
// They'll know exactly what needs abstracting: the actual variations
 
// Year 3: When Apple Pay and BNPL arrive, 
// they'll see the REAL patterns:
// - Some payments confirm immediately
// - Some payments need async confirmation
// - Some require redirect flows
// - Provider is just one dimension of variation
 
// The abstraction they'd build with that knowledge
// would be completely different from the one they guessed at

Key Insight

The team's abstraction wasn't wrong because it was poorly designed—it was wrong because they designed it before understanding the problem. By Year 3, the actual variations (payment flow types) were orthogonal to their predicted variations (payment providers).

Recognizing Premature Abstraction Patterns

Premature abstraction can be identified by characteristic warning signs. Here are concrete patterns to watch for:

Warning Signs of Premature Abstraction

•"We might need..." — Any abstraction justified with future possibilities rather than current realities is premature. "We might need" is speculation, not engineering.
•First Implementation Is Generic — The first implementation shouldn't be a framework. It should be concrete code that solves the immediate problem.
•Interface Before Implementation — Designing interfaces before you've written two or three implementations is often premature. You don't know the right abstraction yet.
•More Parameters Than Uses — When an abstraction has configuration options that aren't used anywhere, you've generalized based on imagination rather than need.
•Complex Solution to Simple Problem — If the abstraction machinery is more complex than the problem it solves, you've over-engineered upfront.
•Speculative Extension Points — Plugin systems, hook mechanisms, or callback registries with no registered plugins or hooks yet.

Premature Abstraction Signals

•"We're building for the future"
•Interface has one implementation
•Framework extracted from single project
•Scaling for users you don't have
•Pattern applied without problem
•Configuration no one uses

Appropriate Abstraction Signals

•"We've seen this three times now"
•Interface extracted from real variations
•Framework based on multiple applications
•Scaling for measured growth
•Pattern solves recurring pain
•All configuration options used

The Evidence Test

For any abstraction, ask: "What concrete evidence justifies this?" If the answer involves predictions, speculation, or "might," the abstraction is likely premature. Appropriate abstractions are justified by existing code patterns, not imagined ones.

Strategies to Avoid Premature Abstraction

Avoiding premature abstraction requires developing patience and judgment. Here are proven strategies:

Prevention Strategies

•The Rule of Three, Strictly Applied — Don't abstract until you have three concrete instances. The first is unique. The second might be coincidence. The third reveals the pattern. Wait for the third before generalizing.
•Build Vertical Slices First — Complete features end-to-end before abstracting horizontally. A working feature teaches you about real requirements; abstract layers teach you nothing until they're used.
•Make the Change Easy, Then Make the Easy Change — Kent Beck's advice: first refactor to make your change simple, then make the simple change. Don't refactor for changes you're not making.
•Tolerate Some Duplication — Copy-paste is cheaper than wrong abstraction. When you copy code, you preserve the option to abstract correctly later. Wrong early abstraction removes that option.
•Wait for Pain — Abstraction should relieve existing pain, not prevent hypothetical future pain. When lack of abstraction causes real problems (bugs from duplication, change propagation), then abstract.
•YAGNI as Default Policy — "You Aren't Gonna Need It" should be your default assumption. When you imagine future requirements, your imagination is usually wrong.
•Refactor, Don't Anticipate — Write concrete code first. When you see the pattern clearly from multiple examples, extract it. Extraction-based abstraction is grounded in reality; anticipation-based abstraction is speculation.

The discipline of waiting:

Avoiding premature abstraction requires genuine discipline. Experienced engineers often can see the abstraction that might be needed. The temptation to build it immediately is strong. But seeing a possible abstraction and knowing it's the right abstraction are different.

The discipline is in saying: "I see where this could go, but I'll wait until I have evidence." This isn't laziness—it's intellectual humility about our ability to predict the future.

Documentation as Alternative

If you see a potential abstraction but lack evidence, document your observation instead of implementing it. A comment or design doc saying "if we add X and Y, we should abstract pattern Z" captures the insight without committing to speculation.

The Sandi Metz Insight: Duplication Is Far Cheaper

Sandi Metz, a renowned software developer and author, crystallized a crucial insight about abstraction timing that deserves special attention:

The Sandi Metz Principle

"Duplication is far cheaper than the wrong abstraction." — Sandi Metz

This principle deserves unpacking because it contradicts the "DRY" (Don't Repeat Yourself) principle that many engineers treat as sacred.

Why duplication is cheaper:

Duplication vs. Wrong Abstraction

•Duplication is local — Duplicated code affects only its immediate context. Wrong abstraction affects everywhere that depends on it.
•Duplication is visible — You can see duplicated code. Wrong abstractions hide their wrongness behind apparently reasonable interfaces.
•Duplication is easy to fix — Extracting an abstraction from duplication is straightforward once you understand the pattern. Fixing a wrong abstraction often requires rearchitecting.
•Duplication preserves options — Each duplicate is independent. You can abstract from any of them. Wrong abstractions constrain all their consumers.
•Duplication fails explicitly — If one duplicate has a bug, you see it locally. Wrong abstractions cause subtle, distributed failures.

The DRY nuance:

DRY doesn't mean "never repeat any code." It means "don't repeat knowledge." Two pieces of code can look identical but represent different domain concepts that should evolve independently. Abstracting them creates a false coupling.

Consider: tax calculation for orders and tax calculation for refunds might use the same formula today. But they represent different business rules that regulators might change independently. Abstracting them forces future changes to affect both, when the business might want them separate.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Two similar-looking functions that represent different concepts
 
// Order tax calculation - subject to order-specific regulations
function calculateOrderTax(order: Order): Money {
    // Looks like refund tax calculation, but is it the same concept?
    return order.subtotal.multiply(0.08);
}
 
// Refund tax calculation - subject to refund-specific regulations  
function calculateRefundTax(refund: Refund): Money {
    // In some jurisdictions, refund tax rules differ from order tax
    return refund.amount.multiply(0.08);
}
 
// Bad abstraction: prematurely unifying them
function calculateTax(amount: Money, type: 'order' | 'refund'): Money {
    // Now if refund tax rules change, we must not break order tax
    // The abstraction creates coupling where the domain has none
    return amount.multiply(0.08);
}
 
// Better: leave them separate until evidence shows they're truly unified
// If regulations cause them to diverge, the duplication handled it
// If they remain the same for years, then consider abstracting
 
// The cost of waiting: ~50 lines of duplication
// The cost of wrong abstraction: coordinated changes, potential bugs,
// difficulty explaining why they're unified, constraint on future evolution

The Litmus Test for DRY

Before eliminating duplication, ask: "If one of these changed, should the other change too?" If the answer is unclear or "not necessarily," the duplication might be appropriate. DRY applies to knowledge, not to textually similar code.

Summary: The Discipline of Timely Abstraction

Premature abstraction is a timing failure: creating the right abstraction before you have the evidence to design it correctly. Let's consolidate the essential insights:

Key Takeaways

•Premature abstraction is speculation embedded in code — Abstractions based on "might need" rather than evidence are guesses, and guesses are usually wrong.
•Abstractions become constraints once established — Wrong early abstractions lock you into decisions made with insufficient information.
•Rule of Three is a minimum — Don't abstract until you've seen the pattern three times. Even then, question whether the similarities are essential or coincidental.
•Duplication is cheaper than wrong abstraction — You can always extract duplication later; fixing wrong abstraction requires rearchitecting.
•YAGNI is wisdom, not laziness — Assuming you won't need it is usually correct. Build for what you know, not what you imagine.
•Wait for pain, then abstract — Real pain (bugs from duplication, change propagation) is evidence that abstraction is needed. Hypothetical pain is speculation.
•Extraction beats anticipation — Build concrete code, see patterns emerge, then extract. Don't anticipate patterns before you've experienced them.

What's Next:

We've explored the three faces of wrong abstraction: too much (over-abstraction), too little (under-abstraction), and too soon (premature abstraction). The final page synthesizes these lessons into a practical diagnostic framework: how to recognize the signs of wrong abstraction in any codebase and what to do about them.

Page Complete

You now understand premature abstraction: why timing matters, what makes abstraction premature, its costs, warning signs, and prevention strategies. The key insight is that good abstraction requires evidence from experience—and evidence takes time to gather.

3 / 4

Loading learning content...

System Design (LLD)The Cost of Wrong Abstractions

The Cost of Wrong Abstractions

LevelIntermediate

Duration90 mins

TopicThe Cost of Wrong Abstractions

3 / 4

Premature Abstraction — The Timing Problem

The Danger of Abstracting Too Soon

What You Will Learn

What Makes Abstraction Premature

Premature abstraction typically manifests in these patterns:

Characteristics of Premature Abstraction

•First-Version Generalization — Abstracting before you've written the first concrete implementation. You can't know what to abstract before you know what works.
•Predicted Variations — Building interfaces for variations that might exist. "We might need different payment providers someday."
•Engineering for Scale Before Users — Designing for millions of users when you have hundreds. Scaling problems are specific; you can't solve them in advance.
•Architectural Patterns Without Problems — Applying microservices, event sourcing, or CQRS because they're "best practices," not because your system needs them.
•Framework Extraction Too Early — Extracting a reusable framework after building only one or two applications in the space.

The Core Insight

Why Timing Matters in Abstraction

Consider the lifecycle of an abstraction:

Abstraction Lifecycle and Change Cost
Stage	Description	Cost to Change
Creation	Abstraction is defined and first used	Minimal (just delete it)
Adoption	Multiple consumers depend on abstraction	Moderate (must update consumers)
Entrenchment	Abstraction shapes architectural decisions	High (requires significant refactoring)
Petrification	Changing abstraction would break external contracts	Very High (may be practically impossible)

The wrong abstraction locks you in:

When you abstract prematurely, you commit to a generalization before understanding the specific cases. When reality diverges from your predictions (which it almost always does), you face a dilemma:

Adapt the implementation to fit the wrong abstraction — This creates awkward code that fights against the abstraction's assumptions.
Extend the abstraction to cover new cases — This bloats the abstraction with special cases, destroying its coherence.
Replace the abstraction entirely — This requires updating all consumers and may introduce regressions.

All three options are costly. None would have been necessary if you'd waited for clarity before abstracting.

The Wisdom of Waiting

The Costs of Premature Abstraction

Premature abstraction combines the costs of over-abstraction with the additional cost of being wrong. Here are the specific ways it damages projects:

The Cost Dimensions of Premature Abstraction

•Immediate Overhead Without Benefit — You pay the complexity cost of abstraction (indirection, interfaces, generalization) before any benefit materializes. If the predicted variations never arrive, the cost is pure loss.
•Wrong Flexibility Points — You make the system flexible in places that don't need to change, while the parts that actually need to change are hardcoded around the wrong abstraction.
•Delayed Understanding — By generalizing too soon, you stop learning about the specific cases. The abstraction obscures the concrete behavior you need to understand.
•Constraint on Future Solutions — The premature abstraction constrains future design decisions. Better approaches may be impossible because they'd require abandoning the abstraction.
•Team Cognitive Load — Team members must understand the abstraction before they can work in the area, even though the abstraction doesn't yet solve a real problem.
•Maintenance of Unused Generality — Tests, documentation, and code reviews all carry the burden of abstraction that provides no value.

The speculation tax:

The expected value is negative: the cost of wrong abstraction exceeds the cost of delayed abstraction, multiplied by the probability of being wrong (which, for speculation, is high).

The Compounding Problem

Case Study: The Premature Plugin System

Let's examine a realistic example of premature abstraction and its consequences. A team builds an e-commerce system and anticipates they might need multiple payment providers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Year 1: Team anticipates multiple payment providers
// They build a full abstraction layer before having any
 
interface PaymentProvider {
    initialize(config: ProviderConfig): Promise<void>;
    createPayment(amount: Money, metadata: PaymentMetadata): Promise<PaymentIntent>;
    confirmPayment(intentId: string): Promise<PaymentResult>;
    refundPayment(paymentId: string, amount?: Money): Promise<RefundResult>;
    listTransactions(filter: TransactionFilter): Promise<Transaction[]>;
    getProviderInfo(): ProviderInfo;
}
 
interface PaymentProviderFactory {
    create(providerType: ProviderType): PaymentProvider;
    register(type: ProviderType, factory: () => PaymentProvider): void;
}
 
class PaymentService {
    constructor(
        private providerFactory: PaymentProviderFactory,
        private providerRegistry: ProviderRegistry,
        private configLoader: ProviderConfigLoader
    ) {}
    
    async processPayment(request: PaymentRequest): Promise<PaymentResult> {
        const providerType = this.determineProvider(request);
        const provider = this.providerFactory.create(providerType);
        const config = await this.configLoader.load(providerType);
        await provider.initialize(config);
        const intent = await provider.createPayment(request.amount, request.metadata);
        return provider.confirmPayment(intent.id);
    }
}
 
// 500 lines of abstractions, factories, registries...
// For a single Stripe implementation that took 50 lines

Three years pass. What happened?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Year 3: Reality Check
 
// The business still only uses Stripe
// But now they need:
// - Apple Pay (different flow, not provider-based)
// - Buy Now Pay Later (requires checkout session, breaks interface)
// - Subscriptions (completely different model)
// - Regional routing (not provider selection)
 
// The premature abstraction:
// 1. Assumed payment methods would be interchangeable (wrong)
// 2. Assumed a factory pattern would handle selection (wrong)
// 3. Didn't anticipate flow differences (partially-confirmed payments, delayed)
// 4. Made it hard to add Apple Pay (it's not a "provider")
 
// The team now faces:
// - Rewriting the abstraction to accommodate real requirements
// - Or hacking around it with special cases
// - 500 lines of never-used generality wasted
// - Wrong mental model embedded in the codebase

What should they have done instead?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// Year 1: Just use Stripe directly
 
class PaymentService {
    constructor(private stripe: Stripe) {}
    
    async processPayment(amount: Money, customer: Customer): Promise<PaymentResult> {
        const intent = await this.stripe.paymentIntents.create({
            amount: amount.cents,
            currency: amount.currency,
            customer: customer.stripeId,
        });
        
        return {
            id: intent.id,
            status: intent.status,
            amount: amount,
        };
    }
}
 
// 50 lines, clear, directly testable
// When/if they need PayPal, they can abstract then
// They'll know exactly what needs abstracting: the actual variations
 
// Year 3: When Apple Pay and BNPL arrive, 
// they'll see the REAL patterns:
// - Some payments confirm immediately
// - Some payments need async confirmation
// - Some require redirect flows
// - Provider is just one dimension of variation
 
// The abstraction they'd build with that knowledge
// would be completely different from the one they guessed at

Key Insight

Recognizing Premature Abstraction Patterns

Premature abstraction can be identified by characteristic warning signs. Here are concrete patterns to watch for:

Warning Signs of Premature Abstraction

•"We might need..." — Any abstraction justified with future possibilities rather than current realities is premature. "We might need" is speculation, not engineering.
•First Implementation Is Generic — The first implementation shouldn't be a framework. It should be concrete code that solves the immediate problem.
•Interface Before Implementation — Designing interfaces before you've written two or three implementations is often premature. You don't know the right abstraction yet.
•More Parameters Than Uses — When an abstraction has configuration options that aren't used anywhere, you've generalized based on imagination rather than need.
•Complex Solution to Simple Problem — If the abstraction machinery is more complex than the problem it solves, you've over-engineered upfront.
•Speculative Extension Points — Plugin systems, hook mechanisms, or callback registries with no registered plugins or hooks yet.

Premature Abstraction Signals

•"We're building for the future"
•Interface has one implementation
•Framework extracted from single project
•Scaling for users you don't have
•Pattern applied without problem
•Configuration no one uses

Appropriate Abstraction Signals

•"We've seen this three times now"
•Interface extracted from real variations
•Framework based on multiple applications
•Scaling for measured growth
•Pattern solves recurring pain
•All configuration options used

The Evidence Test

Strategies to Avoid Premature Abstraction

Avoiding premature abstraction requires developing patience and judgment. Here are proven strategies:

Prevention Strategies

•The Rule of Three, Strictly Applied — Don't abstract until you have three concrete instances. The first is unique. The second might be coincidence. The third reveals the pattern. Wait for the third before generalizing.
•Build Vertical Slices First — Complete features end-to-end before abstracting horizontally. A working feature teaches you about real requirements; abstract layers teach you nothing until they're used.
•Make the Change Easy, Then Make the Easy Change — Kent Beck's advice: first refactor to make your change simple, then make the simple change. Don't refactor for changes you're not making.
•Tolerate Some Duplication — Copy-paste is cheaper than wrong abstraction. When you copy code, you preserve the option to abstract correctly later. Wrong early abstraction removes that option.
•Wait for Pain — Abstraction should relieve existing pain, not prevent hypothetical future pain. When lack of abstraction causes real problems (bugs from duplication, change propagation), then abstract.
•YAGNI as Default Policy — "You Aren't Gonna Need It" should be your default assumption. When you imagine future requirements, your imagination is usually wrong.
•Refactor, Don't Anticipate — Write concrete code first. When you see the pattern clearly from multiple examples, extract it. Extraction-based abstraction is grounded in reality; anticipation-based abstraction is speculation.

The discipline of waiting:

The discipline is in saying: "I see where this could go, but I'll wait until I have evidence." This isn't laziness—it's intellectual humility about our ability to predict the future.

Documentation as Alternative

The Sandi Metz Insight: Duplication Is Far Cheaper

Sandi Metz, a renowned software developer and author, crystallized a crucial insight about abstraction timing that deserves special attention:

The Sandi Metz Principle

"Duplication is far cheaper than the wrong abstraction." — Sandi Metz

This principle deserves unpacking because it contradicts the "DRY" (Don't Repeat Yourself) principle that many engineers treat as sacred.

Why duplication is cheaper:

Duplication vs. Wrong Abstraction

•Duplication is local — Duplicated code affects only its immediate context. Wrong abstraction affects everywhere that depends on it.
•Duplication is visible — You can see duplicated code. Wrong abstractions hide their wrongness behind apparently reasonable interfaces.
•Duplication is easy to fix — Extracting an abstraction from duplication is straightforward once you understand the pattern. Fixing a wrong abstraction often requires rearchitecting.
•Duplication preserves options — Each duplicate is independent. You can abstract from any of them. Wrong abstractions constrain all their consumers.
•Duplication fails explicitly — If one duplicate has a bug, you see it locally. Wrong abstractions cause subtle, distributed failures.

The DRY nuance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Two similar-looking functions that represent different concepts
 
// Order tax calculation - subject to order-specific regulations
function calculateOrderTax(order: Order): Money {
    // Looks like refund tax calculation, but is it the same concept?
    return order.subtotal.multiply(0.08);
}
 
// Refund tax calculation - subject to refund-specific regulations  
function calculateRefundTax(refund: Refund): Money {
    // In some jurisdictions, refund tax rules differ from order tax
    return refund.amount.multiply(0.08);
}
 
// Bad abstraction: prematurely unifying them
function calculateTax(amount: Money, type: 'order' | 'refund'): Money {
    // Now if refund tax rules change, we must not break order tax
    // The abstraction creates coupling where the domain has none
    return amount.multiply(0.08);
}
 
// Better: leave them separate until evidence shows they're truly unified
// If regulations cause them to diverge, the duplication handled it
// If they remain the same for years, then consider abstracting
 
// The cost of waiting: ~50 lines of duplication
// The cost of wrong abstraction: coordinated changes, potential bugs,
// difficulty explaining why they're unified, constraint on future evolution

The Litmus Test for DRY

Summary: The Discipline of Timely Abstraction

Premature abstraction is a timing failure: creating the right abstraction before you have the evidence to design it correctly. Let's consolidate the essential insights:

Key Takeaways

•Premature abstraction is speculation embedded in code — Abstractions based on "might need" rather than evidence are guesses, and guesses are usually wrong.
•Abstractions become constraints once established — Wrong early abstractions lock you into decisions made with insufficient information.
•Rule of Three is a minimum — Don't abstract until you've seen the pattern three times. Even then, question whether the similarities are essential or coincidental.
•Duplication is cheaper than wrong abstraction — You can always extract duplication later; fixing wrong abstraction requires rearchitecting.
•YAGNI is wisdom, not laziness — Assuming you won't need it is usually correct. Build for what you know, not what you imagine.
•Wait for pain, then abstract — Real pain (bugs from duplication, change propagation) is evidence that abstraction is needed. Hypothetical pain is speculation.
•Extraction beats anticipation — Build concrete code, see patterns emerge, then extract. Don't anticipate patterns before you've experienced them.

What's Next:

Page Complete

3 / 4