Not Every Change is Foreseeable - Balancing OCP with Pragmatism | OneNoughtOne

0/290

System Design (LLD)Balancing OCP with Pragmatism

Balancing OCP with Pragmatism

LevelIntermediate

Duration75 mins

TopicBalancing OCP with Pragmatism

1 / 4

Not Every Change is Foreseeable

The Illusion of Perfect Foresight

There is a seductive trap in software design: the belief that with enough analysis, experience, and insight, we can anticipate every future change our system might need to accommodate. Armed with the Open/Closed Principle, developers sometimes fall into a pattern of building elaborate extension mechanisms for changes that never materialize—while being blindsided by changes they never imagined.

This page confronts an uncomfortable truth: we are remarkably bad at predicting the future of our software. The history of software engineering is littered with systems that were carefully designed to be open for extension in precisely the wrong dimensions, while remaining stubbornly closed in the areas where change actually occurred.

What You Will Learn

By the end of this page, you will understand why future requirements are fundamentally unpredictable, how this uncertainty should shape your approach to OCP, and what strategies allow you to embrace uncertainty rather than futilely resist it. You'll learn to distinguish between the impossible dream of perfect foresight and the practical art of evolutionary design.

The Prediction Problem

Software requirements emerge from a complex intersection of business strategy, market conditions, user behavior, technological capability, and competitive pressure. Each of these factors is itself unpredictable, and their interactions create a combinatorial explosion of possible futures.

Why prediction fails:

Consider a typical software project at inception. The development team might know:

The current business model and immediate user needs
The technical constraints of today's infrastructure
The competitive landscape as it currently exists
The regulatory environment at the present moment

What they cannot know includes:

How user behavior will evolve as the product matures
What competitors will introduce next quarter or next year
How business priorities will shift with market conditions
What new technologies will emerge and become expectations
When regulations will change and in what direction
Which features users think they want versus what they'll actually use

The further we project into the future, the more our predictions diverge from reality. A design decision intended to accommodate change two years from now is essentially a gamble—and the house usually wins.

Survivorship Bias in Design Narratives

Case studies of successful prediction create a false impression. We hear about the teams who correctly anticipated a major change and designed for it. We don't hear about the far more numerous teams who predicted wrongly—either building extension points that remained forever unused, or preparing for changes that never came while being devastated by changes they never imagined.

The Anatomy of Unpredictability

To understand why change is unpredictable, we must examine the different sources of unpredictability in software systems. Each source creates different challenges for design foresight.

Sources of Unpredictable Change
Source	Nature of Unpredictability	Design Impact
Business Pivots	Strategic direction shifts based on market feedback, funding, or leadership changes	Core assumptions invalidated; extension points may become irrelevant
User Discovery	Actual user behavior differs from imagined use cases	Features designed for flexibility in unused areas; rigidity where flexibility needed
Competitive Response	Competitor actions force reactive feature development	Planned timelines disrupted; rushed changes to closed components
Technological Shifts	New technologies change what's possible and expected	Today's extension points may not accommodate tomorrow's paradigms
Regulatory Changes	Legal requirements can mandate fundamental changes	Compliance may require modifying what was designed as closed
Scale Effects	Problems that emerge only at certain scales	Performance changes may require structural modifications
Integration Pressure	Requirements from partners or platforms we integrate with	External constraints on internal design decisions

The compounding effect:

These sources don't operate in isolation. A business pivot triggered by competitive pressure might coincide with a regulatory change—and the combination requires changes no one could have predicted from either factor alone.

Example: The Payment Processing Evolution

Consider a team building a payment system in 2015:

They might design for multiple credit card processors (a predictable variability)
They might add an extension point for different currencies (sensible)
They might even anticipate mobile payments (prescient)

But could they predict:

Cryptocurrency payment requirements emerging based on user demand?
Buy-now-pay-later integration becoming a competitive necessity?
Real-time payment regulations mandating fundamental flow changes?
Global compliance requirements for data residency?
Embedded finance requiring modularization they never anticipated?

No amount of careful analysis in 2015 would have identified these specific dimensions of change. A team that built extensive extension mechanisms for multiple card processors might find themselves with no easy path to cryptocurrency—because the abstraction was built around assumptions that don't transfer.

The Dimensionality Problem

When we design for extensibility, we're essentially choosing which 'axes' the system can easily extend along. But future requirements often demand extension along axes we never considered—or require changes that cross multiple axes simultaneously. We can't build extension points for dimensions we haven't imagined.

Case Studies in Failed Prediction

Let's examine real-world patterns where prediction failed, illustrating how even experienced teams building with the best intentions find their foresight inadequate.

Case Study 1: The Over-Abstracted Notification System

•Initial Design: A team anticipates needing multiple notification channels. They build an elaborate abstraction: NotificationChannel interface, NotificationRouter, ChannelFactory, NotificationTemplateEngine.
•Extension Points Built: Email, SMS, push notifications, webhook—all cleanly pluggable via the Strategy pattern.
•The Reality: Three years later, the only channels ever used are email and push. But now the business needs in-app notification with read receipts and user preferences tied to notification type.
•The Problem: The abstraction treated notifications as fire-and-forget. The new requirements need bidirectional communication and stateful user preferences—capabilities orthogonal to the extensibility that was built.
•Cost: The team can't use their extension points. They must modify the 'closed' core to add state tracking—a harder change than if they'd built a simpler system that evolved incrementally.

Case Study 2: The Prematurely Flexible Pricing Engine

•Initial Design: Anticipating complex pricing models, the team builds a rule engine with pluggable PricingRule implementations, supporting composition and evaluation order.
•Extension Points Built: Percentage discounts, fixed discounts, tiered pricing, bulk pricing—all configurable without code changes.
•The Reality: The business never uses complex pricing. But they now need dynamic pricing based on inventory levels and competitor pricing with sub-second response times.
•The Problem: The rule engine introduced evaluation overhead. Dynamic pricing requires external data integration and caching strategies the abstraction never considered.
•Cost: The extensible rule engine becomes a liability. Real-time pricing requires bypassing the abstraction or rebuilding it—paying the maintenance cost of unused flexibility while doing the work of a new implementation.

Case Study 3: The Database-Agnostic Repository

•Initial Design: Concerned about database lock-in, the team builds a repository abstraction hiding all database details behind interfaces.
•Extension Points Built: The repository interface allows swapping databases without changing application code.
•The Reality: The database never changes. But the application needs database-specific features: PostgreSQL's JSONB queries, partial indexes, and materialized views.
•The Problem: The abstraction forbids accessing these features without 'breaking' the interface contract. The team faces a choice: abstraction or performance.
•Cost: Either the abstraction is violated (making it useless), or performance suffers for an abstraction providing no actual value. Often, both—the abstraction is selectively bypassed, creating inconsistent patterns.

Pattern Recognition

In each case, the teams were competent and thoughtful. They applied OCP correctly. Their failure wasn't in execution—it was in the fundamental assumption that they could predict the future. The lesson isn't 'their extension points were wrong'; it's that extension points are guesses, and most guesses are wrong.

The Knowledge Gap at Design Time

A fundamental asymmetry exists between design time and runtime. At design time, we have the least information about what our system will need to do. Yet design time is when we must make structural decisions that constrain future possibilities.

What we know at design time:

Current requirements (already potentially obsolete)
Stakeholder assumptions about the future (often wrong)
Historical patterns from similar projects (context-dependent)
General principles of good design (abstract, not specific)

What we learn during runtime:

Actual user behavior and needs
Real performance characteristics under load
Integration challenges with external systems
Which features matter and which are ignored
How the business context evolves

The paradox: We must design for a future we cannot know, using information that becomes more accurate only as we proceed—when it's often too late to change course without significant cost.

Early Design Decision Information

•Requirements are speculative or incomplete
•User needs are assumed, not validated
•Scale projections are theoretical
•Integration requirements are unknown
•Competitive landscape will evolve
•Technology assumptions may not hold

Information After Production

•Real usage patterns are observable
•Actual performance is measurable
•Integration pain points are known
•User feedback is concrete
•Business priorities have clarified
•Technical constraints are understood

Implications for OCP:

This knowledge asymmetry fundamentally challenges the notion that we can 'close' the right parts of our system. If we don't know what will change, how can we know what should be closed? The answer is that we can't—at least, not with the confidence that OCP seems to promise.

This doesn't mean OCP is useless. It means OCP must be applied with humility: acknowledging that our extension points are educated guesses, not prophecies.

The Cost of Certainty

When developers act as though they know what changes will come, they often over-invest in specific extension mechanisms. When (not if) predictions prove wrong, the over-engineering becomes a liability rather than an asset. Paradoxically, acting with more certainty often leads to worse outcomes than acting with appropriate uncertainty.

Strategies for Embracing Uncertainty

If we accept that we cannot predict the future, how should we approach OCP? The key is shifting from prediction-based design to adaptation-based design.

Core Strategies for Uncertain Futures

•Build for Changeability, Not Specific Changes — Instead of designing for anticipated features, design so that any part of the system can be changed with reasonable effort. Prefer simple, modular designs over complex extension mechanisms.
•Delay Decisions Until the Last Responsible Moment — Don't build abstraction layers before you need them. When you have one implementation, you don't need an interface. When change actually comes, you have more information to guide the abstraction.
•Accept That Some Modifications Are Okay — OCP doesn't mean never modify existing code. It means prefer extension when practical. When the practical extension doesn't exist, modifying well-factored code is acceptable and often preferable to contorted workarounds.
•Invest in Refactoring Capability — If you cannot predict what will change, your best investment is in the ability to change anything. This means comprehensive tests, clear code, manageable coupling, and refactoring skills.
•Build Feedback Loops — Deploy early, gather data, and let actual usage guide design decisions. Extension points should emerge from observed needs, not predicted ones.
•Practice Incremental Design — Don't try to get the design right upfront. Let the design evolve through a series of small, well-tested changes. Each iteration brings more knowledge.
•Keep Extension Points Cheap — If you must guess at extension points, make them low-cost. A simple interface is cheap; an elaborate plugin architecture is expensive. When guesses prove wrong, cheap mistakes are easily corrected.

The Rule of Three

A practical heuristic: Don't abstract until you have three concrete cases. With one case, you're guessing. With two, you might see a pattern but still mostly guessing. With three, you have enough evidence to design an abstraction that actually fits the real variability in your system.

Rethinking 'Closed' as Temporary

A mature understanding of OCP recognizes that 'closed for modification' is never permanent. It represents a current state of stability, not an eternal guarantee.

The lifecycle of closure:

Initial Implementation — Code is written to solve current requirements. It is neither particularly open nor closed—it simply works.
First Change Requirement — A change is needed that the original design didn't anticipate. We have a choice: modify the existing code or introduce an extension point.
Extension Point Creation — If the change represents a pattern likely to recur, we refactor to create an extension point. The specific dimension becomes 'open for extension.'
Temporary Closure — The refactored code is now 'closed' along that dimension. But this closure is provisional—it reflects our current understanding.
New Unanticipated Change — A change arrives that doesn't fit our extension point. We face the choice again: modify the 'closed' code or find a workaround.
Evolving Abstraction — If the new change is valuable, we may modify the abstraction itself. What was closed opens again, incorporating new understanding.

The cycle repeats. There is no final state where the code is perfectly closed. Each period of closure is temporary, lasting until our understanding proves insufficient.

evolution-of-closure.ts
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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// Stage 1: Initial simple implementation
class OrderProcessor {
    process(order: Order): void {
        // Direct implementation - not thinking about OCP yet
        this.validateOrder(order);
        this.calculateTotal(order);
        this.chargePayment(order);
        this.sendConfirmationEmail(order);
    }
}
 
// Stage 2: First change - need SMS notifications too
// We COULD just modify sendConfirmationEmail... but we see a pattern
// So we introduce an extension point
 
interface NotificationSender {
    send(order: Order): void;
}
 
class OrderProcessor {
    constructor(private notifiers: NotificationSender[]) {}
    
    process(order: Order): void {
        this.validateOrder(order);
        this.calculateTotal(order);
        this.chargePayment(order);
        // Now "closed" for notification changes
        this.notifiers.forEach(n => n.send(order));
    }
}
 
// Stage 3: Time passes. Now we need...
// - Notifications with user preferences
// - Different notifications for different order types
// - Notifications that depend on order state changes
 
// Our NotificationSender abstraction doesn't fit!
// It knows nothing about preferences, order types, or state changes.
 
// Stage 4: We must modify what was "closed" - evolve the abstraction
interface NotificationContext {
    order: Order;
    eventType: OrderEventType;
    user: User;
}
 
interface SmartNotificationSender {
    canHandle(context: NotificationContext): boolean;
    send(context: NotificationContext): Promise<void>;
}
 
// The cycle continues - this too will be modified when
// requirements arrive that we can't predict today

Closure as a Promise, Not a Guarantee

Designating code as 'closed' is really a soft commitment: 'We believe this code is stable enough that we don't expect to modify it.' It's a working hypothesis, not a binding contract. When evidence proves the hypothesis wrong, good engineers update their design rather than contort their code to preserve an outdated abstraction.

Practical Guidelines for Unpredictable Change

Given that we cannot predict the future, here are actionable guidelines for applying OCP in the real world:

OCP Guidelines Under Uncertainty
Guideline	Rationale	Example
Start Concrete	Abstractions without concrete experience are guesses	Don't create `PaymentProcessor` interface until you have two payment types
Earn Your Abstractions	Let change requests justify extensions	Add strategy pattern when the second algorithm arrives, not the first
Keep Closed Code Modifiable	Well-tested, clear code is safe to change	High test coverage means opening 'closed' code isn't scary
Track Prediction Accuracy	Learn from past predictions to improve future ones	Review: did those extension points get used? Were changes unexpected?
Accept Rework as Normal	Refactoring isn't failure; it's learning	When predictions fail, refactor enthusiastically rather than defensively
Prefer Shallow Hierarchies	Deep inheritance/composition trees are hard to modify	Flat structures are easier to reorganize when understanding evolves
Limit Blast Radius	Small, focused modules limit the impact of wrong predictions	Changes to one bounded context shouldn't cascade across the system

The meta-guideline: Design as if you will be wrong—because you will be. The goal is not to be right about the future; it's to make being wrong as painless as possible.

This mindset transforms how we think about OCP. Instead of closing code against the changes we predict, we keep code healthy enough that any change—predicted or not—remains feasible. OCP becomes less about preventing modification and more about ensuring that modifications, when necessary, are contained and safe.

Summary: Embracing the Unknown

We've confronted an uncomfortable truth: the future of our software is unknowable. This recognition is not a weakness—it's wisdom that leads to better, more adaptive designs.

Key Takeaways

•Prediction is unreliable — Business pivots, competitive pressure, user behavior, and technological change combine to make the future fundamentally unpredictable.
•Extension points are guesses — When we design for specific extensions, we're betting on particular futures. Most bets lose.
•The knowledge gap is real — We have the least information exactly when we must make binding design decisions. This asymmetry is irreducible.
•Build for adaptability — Rather than predicting specific changes, optimize for the ability to handle any change with reasonable effort.
•Delay abstraction — Wait for concrete needs before abstracting. The Rule of Three provides practical guidance.
•Closure is temporary — 'Closed for modification' is a hypothesis about stability, not a permanent state. Be prepared to update your hypotheses.
•Make being wrong cheap — Design so that incorrect predictions can be corrected without massive rework. This is the true art of sustainable design.

What's next:

Accepting that prediction fails raises a new question: if we try to prepare for unpredictable change, we risk over-engineering—building for changes that never come. The next page explores this tension, examining the real cost of over-engineering and how to recognize when extensibility investments are likely to pay off.

Page Complete

You now understand why software change is fundamentally unpredictable and how this reality should shape your approach to OCP. The key insight: design for changeability rather than predicted changes. Next, we'll explore the cost of over-engineering—what happens when we try too hard to prepare for an unknowable future.